Versions Compared

Version Old Version 1 New Version 2
Changes made by

Anjali Tyagi

Anjali Tyagi

Saved on

Key

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

Lifecycle policy specification includes a cluster setting, policy :

  • Cluster setting

  • Policy headers on domain and bucket objects

...

  • Bucket policies

...

  • stored in Swarm storage (as headers) by the

...

  • gateway

  • Relevant changes to the UIS for lifecycle policies

...

Cluster Setting Values

The CAStor cluster setting policy.lifecycle supports the following two values:

  • disabled – The By default, the evaluation of all lifecycle policies is disabled in the cluster . Generally, the default value disables the feature, giving the legacy behavior, so disabled is the default for the settingto provide legacy behavior.

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

The policy.lifecycle setting will can be persisted and set -able via the Management API and SNMP just like other policy settings.

Policy Header Values

Domain objects supports support a persisted Policy-Lifecycle header that controls the behavior of lifecycle policies for buckets in the domain. The header supports one either of the following values:

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

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

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

Info

Domain objects will NOT do not support policy specification on domains that applies applied to the tenanted content in the domain.

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 have

  • Duplicate names are not allowed within a rule.

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

Supported Attributes

...

Attribute

Value

Definition

RuleId

<unique rule id>

A required, user-defined id of the rule. The required quotes allow spaces in the id. Double quotes in the id must be backslash escaped.

Enabled

<true|false>

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

NamePrefix

<prefix>

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

  • Quotes are required.

The

  • Never use slash as a first character

of

  • for the prefix

should not be a slash. Only if

  • .

  • If the prefix is matched

an

  • with the object name

would

  • , then the rule

be

  • is applied to the object.

  • The absence of this

attribute means that

  • prefix indicates the rule

applies

  • is applied to all

the

  • objects in the bucket.

  • The quotes allow vertical spaces in the prefix.

Double quotes in the prefix

  • The value in quotes must be

backslash escaped

  • URL encoded.

ExpirationDays

<nonnegative integer>

The rule indicates that the current version of the an object should be is expired after some the defined number of days.

ExpirationDate

<ISO 8601 date>

The rule indicates that the current version of the an object should be is expired after the specified defined date (midnight UTC time).

ObsoleteExpirationDays

<nonnegative integer>

The rule indicates that a A non-current version of an object should be is expired after some the defind number of days after the time when the object became becomes non-current. If

Info

This rule impacts nothing if the versioning is not enabled

in

on the bucket

, this rule has no effect

.

ObsoleteExpirationDate

<ISO 8601 date>

The rule indicates that a A non-current version of the object should be is expired after the specified defined date (midnight UTC time). If

Info

This rule impacts nothing if the versioning is not enabled

in

on the bucket

, this rule has no effect

.

Rules with Attributes

Every rule

...

;

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

  • Every rule must Must have an action.

  • A rule May or may not have both ExpirationDays and & ExpirationDate attributes.A rule may not have both ObsoleteExpirationDays and and ObsoleteExpirationDays & ObsoleteExprirationDate attributes.

Expiration Time Rule

  • For expiration days, the expiration time refers to;

    Expiration time = Creation time of the current version + Number of days indicated + Rounded up to the next midnight UTC.

  • For obsolete expiration days, the expiration time refers to;

    Expiration time = Create time of the next newer new object in the versioning chain + Number of days indicated + Round 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 that is not a (i.e. non-delete marker in a the versioning enabled bucket) means to create 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 gateway supports normal SCSP reads & writes of domain and bucket headers with those policies specified. Additionally, the Gateway S3 interface is modified to support GET, PUT, DELETE, and related permissions for bucket lifecycle policies as specified in the S3 documentation (good to have a link). Gateway will validate such validates policies against the S3 specification. On PUT or DELETE , Gateway will translate permission, the gateway translates the client-supplied bucket policy specifications into the appropriate CAStor bucket headers. Aspects of the bucket Bucket lifecycle policies' features that are not supported by CAStor will be Castor does not support, are dropped during this translation, such as storage class transitions. On the bucket lifecycle policy GET reply, Gateway will performs reverse translate translation for any ( Policy-Lifecycle ) headers on the bucket object for its S3 response.

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

Info

Lifecycle 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) will return Policy-Lifecycle-Evaluated and Policy-Lifecycle-Evaluated-Constrained headers describing whether . They describe if the lifecycle policies are in force enforced at the various levels (such as cluster, domain, and bucket).