Exciting stuff in here! > On Apr 10, 2017, at 7:01 PM, Gelinas, Derek <[email protected]> wrote: > > Recently, I have made several changes to both Traffic Ops and the ORT script > as pertains to ATS configuration files. Many of the changes will be seen in > 2.1. These changes do the following: > > > · A configuration file endpoint for individual config files and > metadata. > > · Scope definitions for each configuration file. > > · The ability to point to a reverse proxy for caching – this is now > possible due to the scope changes. EF> What does this mean? Can edge servers now use other reverse proxies as parents? How do we configure this on TO?
> > · A new revalidate option in the ORT script to allow for a check of > the regex_revalidate.config file independent of syncds. EF> Did this clean up all the noisy but harmless ERROR messages in syncds too? > > · Revalidation checks every 60 seconds (configurable) while ORT is in > a dispersal wait state. > > · Use of instant invalidation removes the need for edge caches to > wait for their parent servers’ update flags to clear. EF> Are parent server update flags are still required for syncds? We only ignore them for the “new revalidate”/“instant invalidation” (I assume these are same thing) options? > > Of the 26 file types currently used for ATS configuration, all but 6 of the > files are “CDN” or “profile” scope. In practice this means that for each > profile scope file the requested file will be the same for all servers within > that profile. CDN scope files match across the entire CDN. To accommodate > this, the API includes new metadata that defines the scope and URI needed to > request the configuration file from Traffic Ops. EF> Where can we see the new API? Is scope an input/output/both parameter to the API now? > These changes make it possible to cache the bulk of configuration files > generated by traffic ops, greatly reducing the load on the server(s). ORT > 2.1 and up is expected to use this API, but all new features, such as > revalidate, are used only when enabled ensuring backward compatibility. This > code is currently in master and I welcome any suggestions anyone might have. EF> Will existing API remain as “deprecated” for a few more releases? Upgrade path is very important. I assume we would upgrade TO to 2.1 and then upgrade caches. Will 1.7,1.8,2.0 caches be able to request config files as they do today from a TO2.1? Thanks! —Eric > > Thanks! > Derek > > > > Derek Gelinas > IPCDN Engineering > [email protected]<mailto:[email protected]> > 603.812.5379 >
