Versions Compared

Version Old Version 2 New Version 3
Changes made by

Anjali Tyagi

Brian Guetzlaff

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Lifecycle policy specification includes:

...

Cluster Setting Values

The CAStor Swarm cluster setting policy.lifecycle supports two values:

  • disabled – By default, the evaluation of all lifecycle policies is disabled in the cluster to provide legacy behavior.

  • enabled – Lifecycle policies are may be enabled or disabled at the domain level for domains where such policies are applied.

...

  • <unspecified> – The lack of a defined policy header means that lifecycle policies are only enabled for buckets in the domain when the policy.lifecycle setting is enabled.

  • enabled – The lifecycle policies are enabled for buckets in a domain when the policy.lifecycle cluster setting is enabled.

  • disabled – The lifecycle policies are disabled for buckets in a domain regardless of policy.lifecycle setting. The Policy-Lifecycle value is may be prefixed with a <cluster name>=..., meaning that the policy only applies within the specified cluster. Multiple values are allowed if this feature is used.

Info

Domain objects do not support policy specification applied to the tenanted content in the domainLifecycle policy does not apply to unnamed content within a domain. Only named objects within buckets will have lifecycle policy applied to them.

Bucket objects support a Policy-Lifecycle header with multiple values.

  • Each header value encodes one lifecycle policy.

  • Each Policy-Lifecycle complete rule value is suffixed with “:<cluster name>”, meaning that the policy applies within the specified cluster.

  • Each lifecycle rule is comprised of a number of optional attributes, expressed as <name>:<value> pairs separated by space. Extra spaces are allowed at the beginning, end, and before & after the colon.

Must to haveImportant

  • Duplicate names are not allowed within a rule.

  • Unsupported names or values result in a 400 on the bucket (or domain) write.

...

Attribute

Value

Definition

RuleId

<unique rule id>

A required, user-defined id of the rule. The quotes allow spaces in the id. Double quotes in the id must be backslash escapedvalue must be contained within quotes. Values within the quotes must be URL-encoded.

Enabled

<true|false>

An optional indication to confirm whether the rule is enabled or not. The absence of attribute indicates the rule enabled.

NamePrefix

<prefix>

An optional prefix to be matched against the relative name of the object in question.

  • Quotes are required.

  • Never use slash as a first character for the prefix.

  • If the prefix is matched with the object name, then the rule is applied to the object.

  • The absence of this prefix indicates the rule is applied to all objects in the bucket.

  • The quotes allow vertical spaces in the prefix. The value in quotes must be URL encoded.

ExpirationDays

<nonnegative integer>

The current version of an object is expired after the defined number of days.

ExpirationDate

<ISO 8601 date>

The current version of an object is expired after the defined date (midnight UTC time).

ObsoleteExpirationDays

<nonnegative integer>

A non-current version of an object is expired after the defind defined number of days when the object becomes non-current.

Info

This rule impacts nothing if the versioning is not enabled on the bucket.

ObsoleteExpirationDate

<ISO 8601 date>

A non-current version of the object is expired after the defined date (midnight UTC time).

Info

This rule impacts nothing if the versioning is not enabled on the bucket.

Rules with Attributes

Every rule;:

  • Must have one or multiple more expiration-related attributes.

  • Must have an action.

  • May or may not have ExpirationDays & ExpirationDate attributes and ObsoleteExpirationDays & ObsoleteExprirationDate attributesExpirationDays and ExpirationDate attributes are mutually-exclusive.

  • ObsoleteExpirationDays and ObsoleteExprirationDate attributes are mutually-exclusive.

Expiration Time Rule

  • For expiration days,
    Expiration time = Creation time of the current version + Number of days indicated + Rounded up to the next midnight UTC

  • For obsolete expiration days,
    Expiration time = Create time of the next new object in the versioning chain newest object version + Number of days indicated + Rounded up to the next midnight UTC

  • ISO 8601 dates must unambiguously specify a calendar date. The (unspecified) expiration time is always midnight UTC of that date.

  • Expiration of a current version of an object (i.e. non-delete marker in the versioning enabled bucket) means creating a delete marker, pushing the current version down the versioning stack.

  • In all other cases, the object or object version is permanently deleted.

The gateway supports normal SCSP reads & writes of domain and bucket headers with those policies specified. Gateway S3 interface is modified to support GET, PUT, DELETE, and related permissions for bucket lifecycle policies as specified in the S3 documentation. Gateway validates policies against the S3 specification. On PUT or DELETE permission, the gateway translates the client-supplied bucket policy specifications into the appropriate CAStor Swarm bucket headers. Bucket lifecycle policies' policy features provided via S3 that Castor Swarm does not support , (such as storage class transitions) are dropped during this translation, such as storage class transitions. On the bucket lifecycle policy GET reply, Gateway performs reverse translation for any Policy-Lifecycle headers on the bucket object for its S3 responseinto an S3-compatible format.

UIC provides appropriate editing methods for bucket lifecycle policies at the cluster, domain, and bucket levels.

Info

Since lifecycle policies are part of the overall context-level policy framework, GET and HEAD requests on contexts and name objects (with the verbose query argument) return Policy-Lifecycle-Evaluated and Policy-Lifecycle-Evaluated-Constrained headers. They describe if the lifecycle policies are enforced at the various levels such as cluster, domain, and bucket.

...