ECS support for retention and retention expiration periods for Atmos objects
ECS supports setting retention periods, and retention expiration periods on Atmos objects.
Retention periods
Retention periods define how long ECS retains an object before it can be edited or deleted. During the retention period, the object cannot be edited or deleted from the system until the retention period has expired.
While creating an Atmos object in ECS, the object retention can be:
Defined directly on the object
Inherited from the retention period set on the ECS bucket in which the object is created
When a retention policy is set on the ECS namespace, set the retention period directly on the object. The object does not inherit the retention policy in the namespace.
Table 1. Atmos retention periodsThe table shows the Atmos retention periods
Retention set on the
Using the
Notes
Object
Atmos API through the
Header retention period in seconds:
'x-emc-retention-period:60'
User meta data (UMD), end date:
'x-emc-meta:user.maui.retentionEnable=true,user.maui.retentionEnd=2016-10-21:10:00Z'
Both header, and UMD:
'x-emc-meta:user.maui.retentionEnable = true,user.maui.retentionEnd=2016-10-21T18:14:30Z' -header 'x-emc-retention-period:60'
Retention can be set on the object while creating, or updating the object settings.
Header retention period is defined in seconds.
End date defines the UMD retention.
If retention period is set from both the header and the UMD, the UMD attribute is checked first and takes precedence over the setting in the header.
You cannot modify the retention period after it has been set on the object until the period has expired.
When using the
x-emc header to set retention
If one is defined, -1 sets an infinite retention period and disable the expiration period.
-2 disables the retention period set on the object.
ECS namespace
ECS Portal from the
New Namespace or
Edit Namespace page.
If you want to set a retention period for an object, and a retention policy has been defined on the object user's namespace, you must still define a retention period directly on the object as described earlier.
If a retention policy is set on the ECS namespace, and/or a retention period is set on a bucket within the namespace, and an object is created within the bucket, ECS retains the namespace, bucket, and object for the longest retention periods set for either the namespace, or bucket.
If a retention period has been set on the object itself through the object header, ECS retains the object for the longest time set on the namespace, bucket, or object.
If a retention end date is defined on an object through the Atmos API, ECS uses the Atmos API retention end date set on the object, and ignores the namespace retention policy, and bucket retention periods when creating the object.
While applying a retention policy on a subtenant (bucket) containing Atmos objects, the retention policy is applied to both objects created in the subtenant after the retention policy was set, and objects that were created in the subtenant before the retention policy was set.
ECS REST API
POST /object/namespaces/namespace/{namespace}/retention
ECS bucket
ECS Portal from the
New Bucket, or
Edit Bucket page.
ECS REST API
PUT /object/bucket/{bucketName}/retention
NOTE: For further details about Namespace Retention Policies and Bucket Retention Periods, see the ECS Administration Guide that is available on
https://www.dell.com/support/.
Example: Request and response to create an object with retention set:
When a retention period end date is defined for an Atmos object, and the expiration period is also set on the object, ECS automatically deletes the object at the date that is defined in the expiration period. The expiration period:
Can be set on objects using the Atmos API, or the
x-emc header.
The expiration period must be later than the retention end date.
The expiration period is disabled by default.
When using the
x-emc header to set retention and expiration, a -1 value disables the expiration period.
Example: Set the expiration period using the
x-emc header:
Example: Request and response using the Atmos API:
POST /rest/namespace/file2 HTTP/1.1
User-Agent: curl/7.37.0
Host: 10.247.179.228:9022
Accept: */*
x-emc-date:Thu, 02 Feb 2017 02:47:32 GMT
x-emc-meta:user.maui.expirationEnable=true,user.maui.expirationEnd=2017-03-30T20:20:00Z
x-emc-uid:239e20dec7a54301a0b02f6090edcace/u1
Content-Type:plain/text
x-emc-signature:5tGEyK/9qUZCPSnQ9OPOdktN+Zo=
Content-Length: 10240
Expect: 100-continue
Response
HTTP/1.1 100 Continue
HTTP/1.1 201 Created
Date: Thu, 02 Feb 2017 02:47:33 GMT
x-emc-policy: default
x-emc-request-id: 0af7b3e4:159fb81ddae:345e:0
x-emc-delta: 10240
Location: /rest/objects/5c3abaf60e0e207abec96baf0618c0461b7cd716898f8a12ee236aed1ec94bea-c86ee0e9-8709-4897-898e-c3d1895e1d93
x-emc-mtime: 1486003652813
Content-Length: 0
Server ViPR/1.0 is not blacklisted
Server: ViPR/1.0
Example: Request and response for update meta data with Atmos API:
POST /rest/namespace/file?metadata/user HTTP/1.1
User-Agent: curl/7.37.0
Host: 10.247.179.228:9022
Accept: */*
x-emc-date:Thu, 02 Feb 2017 02:44:13 GMT
x-emc-meta:user.maui.expirationEnable=true,user.maui.expirationEnd=2017-03-30T20:20:00Z
x-emc-uid:239e20dec7a54301a0b02f6090edcace/u1
Content-Type:plain/text
x-emc-signature:9pzcc/Ce4Lq3k52QKdfWLYlZ1Yc=
Response
HTTP/1.1 200 OK
Date: Thu, 02 Feb 2017 02:44:14 GMT
x-emc-policy: _int
x-emc-request-id: 0af7b3e4:159fb81ddae:339e:0
Content-Length: 0
Server ViPR/1.0 is not blacklisted
Server: ViPR/1.0
Retention start delay window
Atmos enables you to specify a start delay window when creating a retention period, which enables you to migrate to ECS. Also, this feature prevents the objects from getting into retention after initial upload of an object.
Atmos creates subtenant request header,
x-emc-retention-start-delay that captures the autocommit interval.
./atmoscurl.pl -user USER1 -action PUT -pmode TID -path / -header "x-emc-retention-period:300" -header "x-emc-retention-start-delay:120" -include
Retention start delay applied on object mtime
In Atmos object creation, if retention start delay is set on the bucket (x-emc-retention-start-delay), the start delay for the object is calculated based on
time-since-mtime of the object.
NOTE: The
time-since-mtime is considered to calculate the start delay as it does not give an exact time to complete an upload and
x-emc-retention-start-delay could be shorter even as a few minutes.
Override bucket-level retention for migrated objects
If the user decides to migrate data through Atmos API to an ECS bucket in a compliant namespace with maui retention headers and if there are any conflicting retentions, the longest retention wins.
On noncompliant buckets, for Atmos migrated objects, the
user.maui*headers specifies the final retention value on an object. If there are no
user.maui*headers available, the longest retention wins.
On object creation in ECS through Atmos API, the
user.maui*headers cannot be combined with any of
x-emc-retention headers.
Atmos API supports GeoDrive
Atmos API supports GeoDrive on ECS. GeoDrive is a windows application that enables Atmos data to be mirrored to the local Windows file system, and it is the same as CIFS-ECS.
Data is not available for the Topic
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please select whether the article was helpful or not.
Comments cannot contain these special characters: <>()\