Hi All, Thanks for the comments and suggestion already added to the detailed spec <https://docs.google.com/document/d/1Dfy-iYxR8CQzxXx8cnJ68hrN3kr3R2mFP2no_fDouHc/edit?usp=sharing> :)
Beyond the feature's "requirements" the document presets a suggestion for TO API changes, internal API adjustments, and DB modificationד. It is opened for comments by everyone, and I would greatly appreciate any additional inputs. Many Thanks, Nir On Fri, Jul 28, 2017 at 5:47 PM, Nir Sopher <[email protected]> wrote: > 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" <[email protected]> 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 >> >
