Caching configuration management

Caching configuration management version 2.0 (deprecated)

Comparison of versions 1.0 and 2.0

Terminology

• Environment service image—a copy of a stored service image that has been promoted to the staging or production environments.
• Property—a Lumen construct consisting of aliases filled by a specified origin. The construct is referred to by the primary alias. Usage associated with all aliases for a given property are collected and made available via the Media portal usage reporting pages or via the Media portal usage API.
• Reporting ID—a new element introduced in HTTP delivery version 2.0. and will emerge as a more flexible way to group usage. Until the Media portal and usage API capabilities have adapted, Reporting ID Name must be set to the primary alias of the V2 representation of a property.
• Service—synonymous with SCID and subscriber.
• Service component ID (SCID)—a service container with the primary purpose of rolling up usage and billing.
• Service image—a structured object used to convey caching behaviors within the CDN network. This term is often used interchangeably with “service” and “configuration”.
• Stored service image—a configuration that is stored but not active unless promoted to an environment.
• Subscriber—a caching service container that holds 1 or more service images. There is a 1:1 relationship between subscriber and SCID.

Simplified URI

One JSON body per service image and few API calls

Creating or updating a configuration in version 1.0 involves several granular API calls to enact caching configuration settings even though they are all for the same subscriber/service. In version 2.0, all settings for a single SCID can be made in a single API call because all configuration settings for the subscriber are represented in a single JSON body.

Stored and environment configuarions

With version 1.0, each SCID contained a single configuration. Changes to this configuration were applied to the CDN network within 15 minutes. With version 2.0, there are several improvements to note:

• multiple stored configurations can be maintained for a single SCID. These are configurations that are not active in the CDN network until they are promoted. Only one configuration may be in an environment at any point in time. Among other benefits, these configurations can be worked on by multiple users until it is time to promote.
  
  
• a staging environment is available for conducting low level testing such as sending curl commands, prior to promoting to production. When promoting a configuration, you will need to specify staging or production. Once acknowledged, most configurations are completed and distributed to the appropriate notes within a minute as opposed to 15 minutes in version 1.0.

When promoting a configuration with many properties, the response wait time can take several minutes. Once the response is received, it will be propagated to the edge within one or two minutes.

More configuration features

Version 2.0 supports more configuration options, such as IP/CIDR groups, accept-encoding overrides, and dynamic content transformation.

Versioning and rollbacks

Stored configurations are versioned, and any version can be promoted to an environment making it easy to revert to a previous version. When saving or promoting, a comment can be provided to aid when reviewing collaborative input from multiple users. Each environment has a version number that represents a count of promotions.

Global definitions and match rules

Except for cache control header override (CCHO) and query string handling (QSH), features are defined once and referred to within match rules reducing the overhead of managing duplicate configuration settings across multiple properties.

ID uniqueness

Within a given instances of a configuration (exp. MyConfig version 1), all element classes, such as a geo region, IDs must be unique. However, origin IDs must be unique at the SCID/subscriber level. Therefore, when promoting a new configuration that contains an origin ID that overlaps with a previously deployed origin ID for a completely different configuration, it will fail. To ensure uniqueness at the SCID/subscriber level, we recommend using a convention, such as appending EPOCH time when generating the ID.

Properties and reporting ID

In order to offer more flexibility in the near future, version 2.0 represents caching properties differently.

Each property must have at least one match rule to match group 0 with a defined traffic type in order to be valid.

Caching configuration management version 1.0 (deprecated)

The presentation of this API is broken into different categories corresponding to the major service configuration components.