Yes. I need to flesh it out a bit more, I think, but it’s in there. I plan to expand the documentation for the new features as well as add documentation for the new API endpoints before we branch 2.1.
Derek On 4/11/17, 11:35 AM, "Robert Butts" <[email protected]> wrote: > Edge and mid servers can use other reverse proxies as their connection to Traffic Ops. This is configured in the GLOBAL parameter profile using the parameter tm.rev_proxy_url. When this is set, the metadata for the server will show a toRevProxyUrl entry under the info section of the JSON > The upd_pending flags still exist and are still used by syncds. We’ve added a new column, reval_pending, which is used for invalidation. When use_reval_pending is set in the GLOBAL profile with a value of 1, the following happens: Is all this in the documentation? It definitely needs to be. On Tue, Apr 11, 2017 at 9:13 AM, Eric Friedrich (efriedri) < [email protected]> wrote: > Thanks Derek- > > - ORT will not update regex_revalidate unless the parents have been > cleared. > EF> Is this based on the parent’s upd_pending or the parent’s > reval_pending? > > - ORT will ignore the upd_pending state of the parents during syncds. > EF> Isn’t it important that parent’s upd_pending be cleared before doing a > syncds on the child? > > > > On Apr 11, 2017, at 9:57 AM, Gelinas, Derek <[email protected]> > wrote: > > > > EF> What does this mean? Can edge servers now use other reverse proxies > as parents? How do we configure this on TO? > > > > DG> Edge and mid servers can use other reverse proxies as their > connection to Traffic Ops. This is configured in the GLOBAL parameter > profile using the parameter tm.rev_proxy_url. When this is set, the > metadata for the server will show a toRevProxyUrl entry under the info > section of the JSON. Info will include profileId, toRevProxyUrl, toUrl, > serverIpv4, ServerTcpPort, serverName, cdnId, cdnName, serverId, and > profileName. If ORT detects the toRevProxyUrl, it will attempt to use that > as the source for all configuration file requests in that run. Should the > specified proxy be down or unreachable, it will revert back to the URL used > in the command line when ORT was started. While there’s no reason a > delivery service for this purpose couldn’t be created, we’ve chosen to run > an ATS instance, configured manually, on each Traffic Ops instance using a > short (~3 minute) TTL. This allows us to keep the caching for Traffic Ops > separate from the CDN we are administering. > > > > 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? > > > > DG> The upd_pending flags still exist and are still used by syncds. > We’ve added a new column, reval_pending, which is used for invalidation. > When use_reval_pending is set in the GLOBAL profile with a value of 1, the > following happens: > > - Invalidation jobs set by either the UI or the API will flag the > reval_pending column instead of upd_pending > > - The update page checked by ORT will show a reval_pending entry > with a true/false value. (Value is null when use_reval_pending is disabled) > > - ORT will perform revalidation checks at the start of each syncds > dispersion and every 60 seconds while the dispersion is running. > > - ORT will not update regex_revalidate unless the parents have > been cleared. > > - ORT will not perform updates of the regex_revalidate file during > syncds. > > - ORT will ignore the upd_pending state of the parents during > syncds. > > > > If use_reval_pending is disabled, syncds will function as it does > today. If an older version of Traffic Ops is in use and the API returns a > 404, ORT will use the currently released method for config files. > > > > EF> Where can we see the new API? Is scope an input/output/both > parameter to the API now? > > > > DG> The API has been merged into master, under app/lib/API/Configs/ApacheTrafficServer.pm > Scope is set in the get_scope() sub. The filename is passed to this sub > and the correct scope is returned. This is primarily used to validate > requests - should the incorrect scope be used, the api will return an error > with the correct scope needed for that file. Each config file’s entry in > the metadata will include the following: > > -fNameOnDisk - the configuration file name > > -location - the file’s location on the cache itself > > -apiUri - the URI to use to download the file from Traffic Ops. > Example: “/api/1.2/cdn/title-vi/configfiles/ats/set_dscp_28.config" > > -scope - the scope of the file > > > > Proper names or the IDs of the server, profile, or cdn can be used > interchangeably. The API will output names rather than IDs for readability. > > > > 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? > > > > DG> Both methods of requesting configuration files remain supported at > this time, and the code changes have been designed so either the caches or > Traffic Ops can be upgraded first. Use of all new features will require > upgrading both, of course. > > > > Hope that answers your questions. Feel free to send any more you might > have my way. > > > > Derek > > > >
