Hi, I took a look at the new "cache key manipulation" plugin. Its API is generalized and very modular comparing to the old "cache url" plugin, built of the following options:
- static-prefix, *capture-prefix*, capture-prefix-uri, remove-prefix - ua-whitelist, ua-blacklist, ua-capture - include-headers - *capture-path*, capture-path-uri, remove-path - exclude-params, include-params, *include-match-params**, * *exclude-match-params*, remove-all-params,sort-params In red I marked the 4 options I suspect to be the most useful in transforming the current "cache url" plugin strings to the new "cache url manipulation" syntax. I believe that from the value given to these options, a simple "cache url" string can also be built. Thinking in this direction, I would suggest to examine a sample of DSes that use the cache-url plugin and see which "cache key manipulations" options are going to be used to support same functionality. Then we can see if we are also able to easily build the old cache-url string back from the new configuration, for supporting the old caches. Finally, we can add a field in the DS per such chosen option, and decide if we want to put the extra effort in the probably simple "translation tool". Of course that the new plugin provide options with no equivalent in the old plugin (e.g "include-headers"). Currently this is not an issue as you are not using this functionality. In the future one may invision some "DS requirement / Cache capability" match mechanism. Bottom line, as I see it, different ATS versions is just a specific use-case of "multi vendor cache". The new plugin is a great example for generalizing the configuration so multiple caches vendors can build their own cfg accordingly. Nir On Wed, Nov 22, 2017 at 6:45 AM, Mark Torluemke <[email protected]> wrote: > I agree -- supporting 3 ATS major versions is likely more work than it's > worth. Traffic Ops core should continue to move towards being cache > software agnostic. > > Having said that, we have some logic today that generates config files > differently, based on the ATS major version: > > https://github.com/apache/incubator-trafficcontrol/blob/a5d9 > ac705c97388bf18c09b32e8ef8434c243354/traffic_ops/app/lib/ > API/Configs/ApacheTrafficServer.pm#L2317 > > > > On Tue, Nov 21, 2017 at 7:52 PM, Jeremy Mitchell <[email protected]> > wrote: > > > IMO, it's a lot to ask of a TC release to support multiple, inherently > > different versions of ATS. We will end up with features or options that > > pertains to one version of ATS but not another. By trying to support too > > many versions of ATS, we complicate TC and if we ever want to implement > any > > type of self-service, we need to simplify TC rather than complicate it. > > > > Not sure how realistic this is but I'd like to see something like this: > > > > Examples: > > > > TC version 2.1 works with ATS 5/6 > > TC version 2.2 works with ATS 5/6 > > TC version 2.3 works with ATS 6/7 <-- sorry, if you are still sitting on > > ATS 5 and want to move to TC 2.3, you need to upgrade ATS > > > > Jeremy > > > > On Tue, Nov 21, 2017 at 3:05 PM, Chris Lemmons <[email protected]> > wrote: > > > > > As we continue the work of getting Traffic Control to work properly > > > with ATS 7 and forward, we're having to re-work some of the ways we > > > manipulate cache keys. The crux of the issue is that cacheurl was > > > deprecated in 6 and has been removed in 7. Cacheurl was replaced with > > > cachekey in 6. That unfortunately will make supporting both 5 and 7 a > > > bit tricky. There are a few options for maintaining compatibility, but > > > I thought I'd ask... would anyone find themselves sad if, at some > > > point, Traffic Control stopped working with version 5 of ATS? And if > > > not, what might be the best way to manage that? > > > > > >
