Versions Compared

Version Old Version 1 New Version Current
Changes made by

Anjali Tyagi

Anjali Tyagi

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Updated the Swarm supported ISO 8601 date formats

...

Table of Contents
minLevel1
maxLevel2
outlinefalse
typelist
printablefalse

Lifecycle policy specification includes:

  • Cluster setting

  • Policy header on domain objects (optional)

  • Policy headers on bucket objects

Cluster Setting Values

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

  • disabled – The A default value for 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 Either enable or disable lifecycle policies at the domain level for domains where such policies should not be are applied.

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

...

.

Domain Setting Values

Domain objects supports support a persisted Policy-Lifecycle header that controls to control 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 represents that lifecycle policies are only enabled for buckets in the domain exactly when the policy.lifecycle setting is enabled. Applying lifecycle policy at the domain level is optional.

  • 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 prefixed with a <cluster name>=, meaning that the policy only applies within the specified cluster. If this feature is used, multiple values are allowed.

Info

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

...

Info

Info

Lifecycle policy is not applied to unnamed content within a domain. Only named objects within buckets contains lifecycle policy applied.

Bucket Setting Values

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

  • Each

...

  • header value encodes

...

  • one lifecycle policy

...

  • rule

...

  • .

  • 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.

Info

Important

  • Duplicate names are not allowed within a ruleacross lifecycle rules for a bucket.

  • Unsupported names or values result in a 400 return an HTTP 400 error on the bucket (or domain) write. The 400 response indicates the source of the problem.

Supported Rule Attributes

The following attributes are supported:

Attribute

Value

Definition

RuleId

<unique rule id>

A required, user-defined

id

ID of the rule. The

required quotes allow spaces in the id. Double quotes in the id must be backslash escaped

value is contained within quotes and must be URL-encoded. Duplicate rule ids (on different Policy-Lifecycle headers) on the same bucket are disallowed.

Enabled

<true|false>

An optional indication

as

to

whether

verify if the rule is enabled. The absence of

the

this attribute indicates the rule

is

enabled.

NamePrefix

<prefix>

An optional prefix to

be matched

match against the relative name of the object in question.

Quotes are required. The first character of the prefix should not be a slash. Only if the prefix matched an object name would the rule be applied to the object. The absence of this attribute means that the rule applies to all the objects in the bucket. The quotes allow vertical spaces in the prefix. Double quotes in the prefix must be backslash escaped.

  • Always use quoted value and verify it is URL encoded

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

  • The rule is applied to the object if the prefix is matched with the object name.

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

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 defined number of days

after the time

when the object

became

becomes non-current.

If

Info

Important

This rule takes effect if 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

Important

This rule takes effect if versioning is

not

enabled

in the bucket, this rule has no effect.

on the bucket.

Note

Swarm supports the following ISO 8601 date formats:

  • 2024-01-01T00:00:00.000Z

  • 2024-01-01T00:00:00Z

  • 2024-01-01T00:00:00

  • 2024-01-01

Rules with Attributes

Every rule

...

:

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

  • Every rule must have an action.

  • A rule may not have both ExpirationDays and ExpirationDate attributes are mutually exclusive.A rule may not have both

  • ObsoleteExpirationDays and ObsoleteExprirationDate attributes are mutually exclusive.

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 object in the versioning chain newest object version + 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; any timezone specification is not allowed.

  • 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 ) represents 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 lifecycle policies specified. Additionally, the The Gateway S3 interface is modified to support GET, PUT, DELETE, and related permissions (GetLifecycleConfiguration and PutLifecycleConfiguration) for bucket lifecycle policies as specified defined 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 Swarm bucket headers. Aspects of the bucket lifecycle policies that are Bucket lifecycle policy features provided using S3 not supported by CAStor will be dropped during this translation, Swarm (such as storage class transitions) are dropped during this translation. 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 appropriate editing methods for bucket lifecycle policies at the cluster, domain, and bucket levels.

...

into an S3-compatible format.

Swarm Content Portal provides a convenient method of managing policies. This information is provided for completeness.

Info

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