You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Gelinas, Derek" <De...@comcast.com> on 2017/04/10 23:01:32 UTC
Recent changes to ATS config file generation
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.
· A new revalidate option in the ORT script to allow for a check of the regex_revalidate.config file independent of syncds.
· 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.
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. 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.
Thanks!
Derek
Derek Gelinas
IPCDN Engineering
Derek_Gelinas@cable.comcast.com<ma...@cable.comcast.com>
603.812.5379
Re: Recent changes to ATS config file generation
Posted by "Gelinas, Derek" <De...@comcast.com>.
I’ve just realized I did not respond to your question about the ORT messages. While I’ve added a great deal of messaging to notify the user about what’s happening with regards to the API, revalidation, and the to_rev_proxy cache, there has not yet been an overhaul of the messages in general, which is what I assume you’re asking about. That said, ORT will most likely be fully overhauled if we move forward with the proposed CDN definition files, so will certainly be improved and clarified at that time. I plan on taking some time at the summit to open up a discussion about the topic of definition files, so we can certainly work that in as well.
Derek
Re: Recent changes to ATS config file generation
Posted by "Gelinas, Derek" <De...@comcast.com>.
On 4/11/17, 11:13 AM, "Eric Friedrich (efriedri)" <ef...@cisco.com> 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?
DG> reval_pending, when use_reval_pending is enabled.
- 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?
DG> Not if you’re not performing invalidation. This was discussed internally, and the conclusion reached was that there are arguments to be made for a tiered approach and arguments against it. If we’re doing things correctly, the best scenario is to build the delivery service, get it loaded onto the CDN (which will be accomplished much more quickly without tiering) and make it active in Traffic Router. But again, we could always add a parameter that tells ORT to respect both upd_pending and reval_pending if that’s something that is needed.
Derek
> On Apr 11, 2017, at 9:57 AM, Gelinas, Derek <De...@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
>
Re: Recent changes to ATS config file generation
Posted by "Gelinas, Derek" <De...@comcast.com>.
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" <ro...@gmail.com> 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) <
efriedri@cisco.com> 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 <De...@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
> >
>
>
Re: Recent changes to ATS config file generation
Posted by Robert Butts <ro...@gmail.com>.
> 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) <
efriedri@cisco.com> 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 <De...@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
> >
>
>
Re: Recent changes to ATS config file generation
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
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 <De...@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
>
Re: Recent changes to ATS config file generation
Posted by "Gelinas, Derek" <De...@comcast.com>.
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
Re: Recent changes to ATS config file generation
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
Exciting stuff in here!
> On Apr 10, 2017, at 7:01 PM, Gelinas, Derek <De...@comcast.com> 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
> Derek_Gelinas@cable.comcast.com<ma...@cable.comcast.com>
> 603.812.5379
>
Re: Recent changes to ATS config file generation
Posted by Dave Neuman <ne...@apache.org>.
Great work Derek!
On Mon, Apr 10, 2017 at 17:01 Gelinas, Derek <De...@comcast.com>
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.
>
> · A new revalidate option in the ORT script to allow for a check
> of the regex_revalidate.config file independent of syncds.
>
> · 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.
>
> 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. 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.
>
> Thanks!
> Derek
>
>
>
> Derek Gelinas
> IPCDN Engineering
> Derek_Gelinas@cable.comcast.com<ma...@cable.comcast.com>
> 603.812.5379
>
>