Policy Specification
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 – A default value for the evaluation of all lifecycle policies in the cluster to provide legacy behavior.
enabled – Either enable or disable lifecycle policies at the domain level for domains where such policies are applied.
Use Management API for policy.lifecycle
setting.
Domain Setting Values
Domain objects support a Policy-Lifecycle
header 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 represents that lifecycle policies are enabled for buckets in the domain 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 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
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.
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 of the rule. The 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 to verify if the rule is enabled. The absence of this attribute indicates the rule enabled. |
NamePrefix | <prefix> | An optional prefix to match against the relative name of the object in question.
|
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. ImportantThis rule takes effect if versioning is enabled on the bucket. |
ObsoleteExpirationDate | <ISO 8601 date> | A non-current version of the object is expired after the defined date (midnight UTC time). |
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 UTCFor obsolete expiration days,
Expiration time = Create time of the next newest object version + Number of days indicated + Rounded up to the next midnight UTCISO 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 (i.e. non-delete marker in the versioning enabled bucket) 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 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 using S3 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.
© DataCore Software Corporation. · https://www.datacore.com · All rights reserved.