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) <[email protected]> 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 >
