On Mon, Dec 26, 2016 at 9:28 AM, Jan van Doorn <[email protected]> wrote:

> You mean we should have deliveryservice <-> parameter directly and not
> deliveryservice <-> profile <-> parameter ?
>
> I think I like using a profile here better. I could see how a set of these
> setting could be re-used over and over again, like a template?
>
>
Yeah, if a deployment has many essentially replicated MSO delivery
services, I can certainly see the advantage of making a template for the
settings.

I'm not sure on the actual implementation -- which profile would the params
go on -- each of the origin ones? Might result in a bunch of profiles
necessary to just change one parameter (thinking HTTP response codes).
Another thing to consider -- we typically make a separate origin profile to
make the cache group hierarchy correct, and a separate profile for
different origin 'weights' (@dg4prez might weigh in, in case I misspoke). I
think the cache group topology is good descriptive information for a
profile, but the 'weight' parameter is something that could also go in a
template concept.


> Rgds,
> JvD
>
>
>
> > On Dec 26, 2016, at 09:21, Mark Torluemke <[email protected]> wrote:
> >
> > Spawning a different email thread from Jan's original for the topic in
> the
> > edited subject line.
> >
> > Thanks,
> > Mark
> >
> > On Mon, Dec 26, 2016 at 8:14 AM, Jan van Doorn <[email protected]> wrote:
> >
> >> Looking at the ATS 6.2 support for TO which requires a deliveryservice
> to
> >> profile mapping, and was wondering why we still have the profile column
> >> (CCR Profile) in deliveryservice?
> >>
> >
> > Feels like Delivery Services should get Parameters (in the same way
> > Profiles and Cache Groups have them) to support the multi-site origin
> > concepts. Maybe just a typo above?
> >
> >
> >>
> >> At first glance it seems to be used for the domain_name parameter only
> >> (?), and that could (should?) be moved to the cdn table? Not sure if
> this
> >> was considered when the cdn table was added and decided against for a
> good
> >> reason?
> >>
> >> Cheers,
> >> JvD
> >>
> >>
>
>

Reply via email to