You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Olsen, Brian (Contractor)" <Br...@comcast.com> on 2018/12/10 19:45:42 UTC
Changing ORT to help with incremental remap rule deployment.
We’ve run into some issues trying to incrementally deploy remap rule plugin changes to our CDN.
One HACKISH way we’ve identified how to do that is by creating an ANY_MAP delivery service and using the Raw Remap Text line to put the change.
To make this work I’ve added a change to ORT to preprocess the remap.config file to look for a commented keyword to do this.
So for example the current active DS FOO_ORIG might create an ATS remap rule like the following:
map http://from.foo http://to.bar
We might want to test a new ATS remap rule:
map http://from.foo http://to.bar @plugin=collapsed_forwarding.so
to deploy on a subset of caches.
So we would create FOO_ANY_MAP as ANY_MAP with raw remap text:
##OVERRIDE## map http://from.foo http://to.bar @plugin=collapsed_forwarding.so
With those subset of caches now being assigned to both FOO_ORIG and FOO_ANY_MAP.
During processing the modified traffic_ops_ort.pl script removes the ‘##OVERRIDE## ‘ from the above rule and also removes the existing FOO_ORIG ‘map http://from.foo http://to.bar’ (based on endpoint match http://from.foo) from the remap.config file.
I had wanted to leave comments in the remap.config file to clearly point out the override and keep the original line in the file but commented out, however that would require either modifying the global logic for change detection or writing a custom remap.config change detection routine.
This updated version of traffic_ops_ort.pl script would need to be deployed before using this ##OVERRIDE## method as will trigger a false positive change in remap.txt every time queues are updated.
This is a HACK designed only live until we get something like versioned delivery services into trafficontrol proper.
Please let me know of any issues, better ways to do the above, etc.
Thanks!
Brian
Re: Changing ORT to help with incremental remap rule deployment.
Posted by Jeff Elsloo <el...@apache.org>.
Hey all,
Once Brian adds documentation for this to PR 3140, I'd like to proceed
with the merge. My reasoning is that we have no real mechanism to
provide functionality similar to delivery service versioning today,
and while a little crude, this does help us to incrementally deploy
changes to delivery services with little disruption. I understand we
will have to maintain this, but hopefully that doesn't become a
problem given how this is isolated to code only in ORT.
I do like the idea of the implicit ANY_MAP override, but that seems a
little too magical for my taste. It's definitely cleaner, but with
Brian's approach, anyone can plainly see by eyeballing remap.config
that something was overridden. Coupled with documentation that
contains the same `##OVERRIDE##` text (i.e.: it's now searchable in
our docs), any concern about clarity or understanding the feature
should be satisfied.
--
Thanks,
Jeff
On Tue, Dec 11, 2018 at 10:22 AM Rawlin Peters <ra...@gmail.com> wrote:
>
> Hey Brian,
>
> If this is really just a temporary hack that will no longer be needed
> once we have versioned delivery services, maybe it should just be a
> one-off local patch to ORT that's only applied to your local ORT
> release rather than something that is upstreamed.
>
> I know it's not really ideal to carry local patches, but it would give
> us incentive to work on proper versioned delivery services in order to
> drop the local ORT patch. If we upstream what you are proposing, then
> even though it's a temporary hack it means that we will have to make
> it a priority to remove it from ORT once we get the proper solution
> implemented. This might also mean providing a proper upgrade path
> (with documentation) to transition between the ORT hack to a versioned
> DS, notifying the mailing list, a deprecation cycle, etc.
>
> Maybe we should just make the override implicit in the ATS config API.
> For example if two conflicting remap FROMs are found for the same
> server, implicitly override the remap line to use the line from the
> ANY_MAP delivery service. Then we could just document that ANY_MAP
> remap lines will take precedence when multiple conflicting remaps are
> found for the same server. I think that is something that would be
> less of a temporary hack and wouldn't really need to be removed later.
>
> - Rawlin
>
> On Mon, Dec 10, 2018 at 12:46 PM Olsen, Brian (Contractor)
> <Br...@comcast.com> wrote:
> >
> > We’ve run into some issues trying to incrementally deploy remap rule plugin changes to our CDN.
> >
> > One HACKISH way we’ve identified how to do that is by creating an ANY_MAP delivery service and using the Raw Remap Text line to put the change.
> >
> > To make this work I’ve added a change to ORT to preprocess the remap.config file to look for a commented keyword to do this.
> >
> > So for example the current active DS FOO_ORIG might create an ATS remap rule like the following:
> >
> > map http://from.foo http://to.bar
> >
> > We might want to test a new ATS remap rule:
> >
> > map http://from.foo http://to.bar @plugin=collapsed_forwarding.so
> >
> > to deploy on a subset of caches.
> >
> > So we would create FOO_ANY_MAP as ANY_MAP with raw remap text:
> >
> > ##OVERRIDE## map http://from.foo http://to.bar @plugin=collapsed_forwarding.so
> >
> > With those subset of caches now being assigned to both FOO_ORIG and FOO_ANY_MAP.
> >
> >
> > During processing the modified traffic_ops_ort.pl script removes the ‘##OVERRIDE## ‘ from the above rule and also removes the existing FOO_ORIG ‘map http://from.foo http://to.bar’ (based on endpoint match http://from.foo) from the remap.config file.
> >
> > I had wanted to leave comments in the remap.config file to clearly point out the override and keep the original line in the file but commented out, however that would require either modifying the global logic for change detection or writing a custom remap.config change detection routine.
> >
> > This updated version of traffic_ops_ort.pl script would need to be deployed before using this ##OVERRIDE## method as will trigger a false positive change in remap.txt every time queues are updated.
> >
> > This is a HACK designed only live until we get something like versioned delivery services into trafficontrol proper.
> >
> > Please let me know of any issues, better ways to do the above, etc.
> >
> > Thanks!
> > Brian
> >
Re: Changing ORT to help with incremental remap rule deployment.
Posted by Rawlin Peters <ra...@gmail.com>.
Hey Brian,
If this is really just a temporary hack that will no longer be needed
once we have versioned delivery services, maybe it should just be a
one-off local patch to ORT that's only applied to your local ORT
release rather than something that is upstreamed.
I know it's not really ideal to carry local patches, but it would give
us incentive to work on proper versioned delivery services in order to
drop the local ORT patch. If we upstream what you are proposing, then
even though it's a temporary hack it means that we will have to make
it a priority to remove it from ORT once we get the proper solution
implemented. This might also mean providing a proper upgrade path
(with documentation) to transition between the ORT hack to a versioned
DS, notifying the mailing list, a deprecation cycle, etc.
Maybe we should just make the override implicit in the ATS config API.
For example if two conflicting remap FROMs are found for the same
server, implicitly override the remap line to use the line from the
ANY_MAP delivery service. Then we could just document that ANY_MAP
remap lines will take precedence when multiple conflicting remaps are
found for the same server. I think that is something that would be
less of a temporary hack and wouldn't really need to be removed later.
- Rawlin
On Mon, Dec 10, 2018 at 12:46 PM Olsen, Brian (Contractor)
<Br...@comcast.com> wrote:
>
> We’ve run into some issues trying to incrementally deploy remap rule plugin changes to our CDN.
>
> One HACKISH way we’ve identified how to do that is by creating an ANY_MAP delivery service and using the Raw Remap Text line to put the change.
>
> To make this work I’ve added a change to ORT to preprocess the remap.config file to look for a commented keyword to do this.
>
> So for example the current active DS FOO_ORIG might create an ATS remap rule like the following:
>
> map http://from.foo http://to.bar
>
> We might want to test a new ATS remap rule:
>
> map http://from.foo http://to.bar @plugin=collapsed_forwarding.so
>
> to deploy on a subset of caches.
>
> So we would create FOO_ANY_MAP as ANY_MAP with raw remap text:
>
> ##OVERRIDE## map http://from.foo http://to.bar @plugin=collapsed_forwarding.so
>
> With those subset of caches now being assigned to both FOO_ORIG and FOO_ANY_MAP.
>
>
> During processing the modified traffic_ops_ort.pl script removes the ‘##OVERRIDE## ‘ from the above rule and also removes the existing FOO_ORIG ‘map http://from.foo http://to.bar’ (based on endpoint match http://from.foo) from the remap.config file.
>
> I had wanted to leave comments in the remap.config file to clearly point out the override and keep the original line in the file but commented out, however that would require either modifying the global logic for change detection or writing a custom remap.config change detection routine.
>
> This updated version of traffic_ops_ort.pl script would need to be deployed before using this ##OVERRIDE## method as will trigger a false positive change in remap.txt every time queues are updated.
>
> This is a HACK designed only live until we get something like versioned delivery services into trafficontrol proper.
>
> Please let me know of any issues, better ways to do the above, etc.
>
> Thanks!
> Brian
>