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
