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 <derek_geli...@comcast.com> 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 >
