At some point it does make sense to make an announced deprecation. Otherwise you end up in a nightmare of (to use the C parlance I'm used to) #ifdefs (or run time checks) all the way down. Its not a huge problem for running the code but it becomes a maintenance nightmare, especially if no one is actively testing all the combinations
Ill start out trying to detect the ATS version, but at some point it should probably be deprecated all together ________________________________________ From: Chris Lemmons <[email protected]> Sent: Wednesday, November 22, 2017 11:00 AM To: [email protected] Subject: Re: Traffic Control with ATS 7+ It's possible to entirely mimic the behaviour of any given cacheurl regex with a properly constructed cachekey parameter set. I haven't tried, but I also suspect it's possible to compile cachekey back for ATS 5, if one really wanted to. TO already has support for cachekey via DS Profiles. It's possible to switch entirely to cachekey right now, except for this one generated use case. It looks like, with Matt's comment, we can probably support 5–7 with just a little logic here. But Mark is 100% correct. Moving toward being cache agnostic is the right solution. I dream of a day when we discover someone is using TC with some cache software we've never heard of, simply by using the API to generate configs. :) That said, I'm not sure it would be accurate to describe ATS 5 as "currently supported". If nobody is using it and nobody is testing it, I'd be a bit surprised if the functionality hasn't accidentally degraded. We may have accidentally deprecated it a few versions ago. :/ On Wed, Nov 22, 2017 at 6:20 AM, Nir Sopher <[email protected]> wrote: > 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? >> > > >> > >>
