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
