Versions Compared

Old Version 9

changes.mady.by.user Anjali Tyagi

Saved on

compared with

New Version Current

changes.mady.by.user 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 Swarm cluster setting policy.lifecycle supports two values:

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

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

The Use Management API for policy.lifecycle setting can be set via Management API.

...

Domain Setting Values

Domain objects support a Policy-Lifecycle header that controls to control the behavior of lifecycle policies for buckets in the domain. The header supports 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 when the policy.lifecycle setting is enabled. This means that setting the Applying lifecycle policy at the domain level is optional.

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

Info

Info

Lifecycle policy does is not apply applied to unnamed content within a domain. Only named objects within buckets will have contains lifecycle policy applied to them.

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 across lifecycle rules for a bucket.

  • Unsupported names or values

...

  • return an HTTP 400 error on the bucket (or domain) write. The 400 response

...

  • indicates the source of the problem.

Supported Rule Attributes

Attribute

Value

Definition

RuleId

<unique rule id>

A required, user-defined

id

ID of the rule. The value

must be

is contained within quotes

. Values within the 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 to

confirm whether

verify if the rule is enabled

or not

. The absence of this attribute indicates the rule enabled.

NamePrefix

<prefix>

An optional prefix to

be matched

match against the relative name of the object in question.

The value must be quoted.

  • Always use quoted value and verify it is URL encoded

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

If

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

, then the rule is applied to the object

  • .

  • The absence of

this

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

  • The quoted value 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 defined number of days when the object becomes non-current.

    Info

    Important

    This rule

    impacts nothing

    takes effect 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

    Important

    This rule

    impacts nothing

    takes effect if

    the

    versioning is

    not

    enabled 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 multiple expiration attributes.

    • ExpirationDays 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 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, so ; any timezone specification is not allowed.

    • Expiration of a current version of an object (i.e. non-delete marker in the versioning enabled bucket) means 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 supports SCSP reads & writes of domain and bucket headers with lifecycle policies specified. 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. Gateway validates policies against the S3 specification. On PUT or DELETE permission, the gateway translates the client-supplied bucket policy specifications into the appropriate Swarm bucket headers. Bucket lifecycle policy features provided via using S3 that Swarm does not support not supported by Swarm (such as storage class transitions) are dropped during this translation. On the bucket lifecycle policy GET reply, Gateway performs reverse translation for any Policy-Lifecycle headers on the bucket object 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) return Policy-Lifecycle-Evaluated and Policy-Lifecycle-Evaluated-Constrained headers. They These headers describe if the lifecycle policies are enforced at the various levels such as cluster, domain, and bucket.