You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by Mark Torluemke <mt...@apache.org> on 2016/12/26 16:21:51 UTC
ATS 6.2 support in Traffic Ops
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 <jv...@knutsel.com> 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
>
>
Re: ATS 6.2 support in Traffic Ops
Posted by Mark Torluemke <ma...@gmail.com>.
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.
On Mon, Dec 26, 2016 at 9:28 AM, Jan van Doorn <jv...@knutsel.com> 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?
>
> Rgds,
> JvD
>
>
>
> > On Dec 26, 2016, at 09:21, Mark Torluemke <mt...@apache.org> 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 <jv...@knutsel.com> 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
> >>
> >>
>
>
Re: ATS 6.2 support in Traffic Ops
Posted by Mark Torluemke <mt...@apache.org>.
On Mon, Dec 26, 2016 at 9:28 AM, Jan van Doorn <jv...@knutsel.com> 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 <mt...@apache.org> 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 <jv...@knutsel.com> 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
> >>
> >>
>
>
Re: ATS 6.2 support in Traffic Ops
Posted by Mark Torluemke <mt...@apache.org>.
On Mon, Dec 26, 2016 at 9:28 AM, Jan van Doorn <jv...@knutsel.com> 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 <mt...@apache.org> 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 <jv...@knutsel.com> 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
> >>
> >>
>
>
Re: ATS 6.2 support in Traffic Ops
Posted by Jan van Doorn <jv...@knutsel.com>.
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?
Rgds,
JvD
> On Dec 26, 2016, at 09:21, Mark Torluemke <mt...@apache.org> 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 <jv...@knutsel.com> 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
>>
>>
Re: ATS 6.2 support in Traffic Ops
Posted by Jan van Doorn <jv...@knutsel.com>.
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?
Rgds,
JvD
> On Dec 26, 2016, at 09:21, Mark Torluemke <mt...@apache.org> 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 <jv...@knutsel.com> 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
>>
>>