Description of problem: Blocker BZ for RHS 2.1 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
http://docs.openstack.org/api/openstack-object-storage/1.0/content/Expiring_Objects-e1e3228.html When an object is assigned either an X-Delete-After or X-Delete-At header when doing a PUT or POST on the object, it is scheduled for deletion. This feature is helpful for objects you do not want to permanently store, such as log files, recurring full backups of a dataset, or documents or images you know will be outdated at a future time. The X-Delete-At header requires a Unix Epoch timestamp, in integer form; for example: 1348691905 represents Wed, 26 Sep 2012 20:38:25 GMT. By setting the header to a specific Epoch time, you indicate when you want the object to expire, not be served, and be deleted completely from the storage system. The X-Delete-After header takes an integer number of seconds and calculates the amount of time from now that you want the object to be deleted. The proxy server that receives the request converts this header into an X-Delete-At header and calculates the deletion time using its current time plus the value given in seconds. For existing objects that you want to assign expiration headers to, use the POST operation.
We need to confirm this is still an issue in RHS2.1.
RHS 2.0 UFO Bugs are being set to low priority.
Being tracked by upstream blueprint : https://blueprints.launchpad.net/gluster-swift/+spec/objectexpirer assigning to Prashanth who is working on the object expiration. *** This bug has been marked as a duplicate of bug 812279 ***