Forgot an important note:) For additional context, see Derek's email discussing "Delivery Service based config generation and Cache Manager", we he suggests a similar concept and examine it from a rollout perspective. I now also noticed the additional remarks by Rob, which further helps in the unification of the 2 suggestions. Nir
On Jul 28, 2017 4:38 PM, "Nir Sopher" <n...@qwilt.com> wrote: > Hi All, > > Following the earlier communication on this thread, as well as the > presentation we had on the summit, we have prepared a detailed spec > <https://docs.google.com/document/d/1Dfy-iYxR8CQzxXx8cnJ68hrN3kr3R2mFP2no_fDouHc/edit?usp=sharing> > for > "delivery-service configuration versioning". > > For your convenience, I'm also pasting here the sections describing the > main functional requirements. > Any input would be greatly appreciated. > > Have a nice weekend, > Nir > > 1. Purpose > > This document is a system functional specification for the “Delivery > Service Configuration Versioning” (DSCV) feature. > 1.1. Scope > > As the amount of delivery-services handled by TC is increasing, denying > the "non dev-ops" user from changing delivery-services (DSs) configuration > by himself, and require a "dev-ops" user to be the one actually making the > changes in the DB, put an increasing load on the operations team. > > We would therefore like to introduce a new workflow, separating the DS > provisioning phase from the deployment. Working in this workflow, the user > changes the DS and when she is ready, she commits the configuration in > order to create a new commited DS version. Later on the operator may decide > which versions to deploy and when. > By following this workflow, the operator may allow the users to push > configurations into the DB, knowing the changes would not be deployed > without his explicit, per DS, consent. > > Another straightforward advantage of using DS versions and specifying the > deployed version, is the ability of a simple delivery service configuration > rollback - providing a quick remedy for configuration errors issues. > > Moreover, we suggest to allow the simultaneous deployment of multiple > versions for the same delivery service. Doing so, while allowing the > operator to orchestrate the usage of the different versions (for example, > via "steering"), the below becomes available: > > 1. > > Manual testing of a new delivery-service configuration, via dedicated > URL / request headers. > 2. > > Staging / Canary testing of new versions, applying them only for a > specific content path, or filtering based on source IP. > 3. > > Gradual transition between the different configuration versions. > 4. > > Configuration versions A/B testing. > 5. > > Immediate (no CRON wait, cr-config change only) delivery-service > version"switch", and specifically immediate rollback capabilities. > > > This document defines the behavior of the system working with DSCV. > It also specifies the list of new/adjusted APIs as well as provide > implementation guidelines. > 2. Feature Overview > 2.1.1. Single / Multi Versioned Delivery Service > > Given a “versioned delivery-service”, the user may use the standard API > (e.g. via Traffic-Portal v2) in order to change the different fields of the > delivery-service. > > Once she is done modifying, the user may fix the current state as a > committed immutable version. The created DS versions can be listed, viewed > and finally deleted by the user. > > Once a DS version is available, the CDN owner may decide to deploy it by > altering the set of “deployed delivery service versions”. > > - > > For a “single versioned” delivery-service, the user may have only a > single version of the delivery-service deployed. > In order to deploy the new version, the CDN owner changes the proper > record in the set of deployed versions, replacing the old version number > with the new one. > - > > For a “multi versioned” delivery-service, multiple versions of the > same delivery service can be deployed simultaneously. > In order to deploy the new version, the CDN owner should add the new > version to the set of deployed versions. The new version can now be used as > a target of a steering DS, allowing a gradual rollout of the DS changes. > > > 2.1.2. Non-Versioned Delivery Service > > The TC owner may decide to keep working in the old, “non-versioned” mode. > Therefore, delivery-services can be marked as having no versions > management. > Like before 2.2, these delivery services latest configuration is deployed > regardless to the newly introduced deployed versions set. > > Future planned features may use the DS versioning to improve the delivery > services configuration modification rollout mechanism. Therefore, adding a > new “non-versioned” delivery service, as well as changing a versioned > delivery service to a “non-versioned” mode, can be blocked globally for the > TC instance, using a “global parameter”, or [future] using a per CDN > configuration. > > 2.1.3. Delivery-Service Revision History > > The user is able to view the table of delivery service versions, and see > the values configured for each version. > > He may also compare two of these versions - easily identifying the > marked-up changes. > 2.1.4. Delivery-Service Configuration Restore > > The user may choose a delivery-service old configuration version, and > restore it as the “head” (not committed) configuration of the > delivery-service. > 2.1.5. Delivery-Service Deployed Versions Limit > > To protect system performance, the number of deployed versions per > delivery service is limited to <TBD>. > This limitation may be globally configured via a “global” profile > parameter. > 2.1.6. Delivery-Service Versions Reporting and Statistics > > The delivery service reporting, based on traffic-stats, is able to provide > the aggregated data for all versions of a delivery-service, as well as > provide the data per DS version. > 2.1.7. Delivery-Service URL Uniqueness > > In order to match content requests to delivery-services, the cache servers > are examining the URL and compare to the Delivery-Services HOST_REGEX. Same > principle holds for different versions of the same “multi versioned” > delivery service. For such a DS we create a different, per DS version, > HOST_REGEX. > > Working with the above mechanism, multi-versioned delivery-services should > have a dedicated certificate per DS version. Once TC-55 > <https://issues.apache.org/jira/browse/TC-55> is implemented, we can > change this requirement, using different PATH_REGEX per delivery service. > > TBD: Default behavior and configuration > 2.1.8. Delivery-Service Profile Versioning > > An open list of delivery-service parameters may reside in a DS-profile > outside of the specific DS main configuration. Starting from TC 2.2, the > DS-profiles can also be versioned, just like the delivery services. > > Every versioned delivery service which is using a profile, must explicitly > indicate the version of the profile. > > [TBD/Future] Profiles revision history & version restore >
