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 <n...@qwilt.com> 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" <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
>>
>

Reply via email to