Description of problem: A 404 is returned for a GET on an expired object. As "object-expirer" daemon is not run in gluster-swift environment, the files however are not deleted from gluster volume. Version-Release number of selected component (if applicable): RHS2.1-GA & RHS2.1-U1 How reproducible: Steps to Reproduce: Few study updates: Gluster-Swift does not support object expiration yet. Object expiration is a two fold task. 1) Store the expiration time to the object metadata. Return 404 when such time elapsed. 2) special service "object-expirer" should run to delete such objects and their metadata <wherever stored>. Gluster-Swift currently does not store X-Delete-At or X-Delete-After header in it's xattr. It has no code to perform cross-checks with current epoch and header's mentioned epoch to return 404 if it has elapsed. This is verified and failed with latest Gluster-Swift code. So this #1 can be implemented in Gluster-Swift with some code changes. Needs more investigation. 2) Interesting thing is in plain swift environment, Openstack Swift stores expiration related metadata of those objects in a special account. SWAuth could be useful in here when we maintain multiple accounts per volume. Openstack Swift's object expirer does walk across such metadata and removes those objects internally. Current account = volume would not work in there. It would need multiple accounts per volume which SWAuth can privide. Just a suggestion. Need to investigate on this further. The "object-expirer" daemon, as of now, depends on a separate special account that keeps track of objects to be deleted. As accounts=volume in gluster-swift, we may have to wait till multiple accounts per volume are implemented OR we could investigate overriding some parts of object-expirer if we want the feature sooner. Actual results: Expected results: Additional info:
New fix does not allow X-Delete-After or X-Delete-At headers to be used in POST and PUT commands. The fix has been merged into the havana branch: http://review.gluster.org/#/c/6444/
Upstream RPMs available here: https://launchpad.net/gluster-swift/havana/1.10.0-1
]# curl -i -v -X PUT -T anaconda-ks.cfg -H 'X-Delete-After: 20' http://10.65.202.205:8080/v1/AUTH_test/cont/obj-exp * About to connect() to 10.65.202.205 port 8080 (#0) * Trying 10.65.202.205... connected * Connected to 10.65.202.205 (10.65.202.205) port 8080 (#0) > PUT /v1/AUTH_test/cont/obj-exp HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > Host: 10.65.202.205:8080 > Accept: */* > X-Delete-After: 20 > Content-Length: 1190 > Expect: 100-continue > < HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request < Content-Length: 52 Content-Length: 52 < Content-Type: text/plain Content-Type: text/plain < X-Trans-Id: tx7623e5c3b3b84071a6178-005391b417 X-Trans-Id: tx7623e5c3b3b84071a6178-005391b417 < Date: Fri, 06 Jun 2014 12:29:11 GMT Date: Fri, 06 Jun 2014 12:29:11 GMT < * Connection #0 to host 10.65.202.205 left intact * Closing connection #0 x-delete-at,x-delete-after headers are not supported[root@RHSS2 ~]# [root@RHSS2 ~]# curl -i -v -X PUT -T anaconda-ks.cfg -H 'X-Delete-At: 87920' http://10.65.202.205:8080/v1/AUTH_test/cont/obj-exp * About to connect() to 10.65.202.205 port 8080 (#0) * Trying 10.65.202.205... connected * Connected to 10.65.202.205 (10.65.202.205) port 8080 (#0) > PUT /v1/AUTH_test/cont/obj-exp HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > Host: 10.65.202.205:8080 > Accept: */* > X-Delete-At: 87920 > Content-Length: 1190 > Expect: 100-continue > < HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request < Content-Length: 52 Content-Length: 52 < Content-Type: text/plain Content-Type: text/plain < X-Trans-Id: txb58a0e573ab249718a5fc-005391b432 X-Trans-Id: txb58a0e573ab249718a5fc-005391b432 < Date: Fri, 06 Jun 2014 12:29:38 GMT Date: Fri, 06 Jun 2014 12:29:38 GMT < * Connection #0 to host 10.65.202.205 left intact * Closing connection #0 x-delete-at,x-delete-after headers are not supported[root@RHSS2 ~]# [root@RHSS2 ~]# Verified On:- #rpm -qa|grep swift openstack-swift-account-1.10.0-3.el6ost.noarch openstack-swift-object-1.10.0-3.el6ost.noarch swiftonfile-1.10.0-6.el6rhs.noarch openstack-swift-plugin-swift3-1.0.0-0.20120711git.1.el6ost.noarch openstack-swift-proxy-1.10.0-3.el6ost.noarch python-swiftclient-1.8.0-1.el6ost.noarch openstack-swift-container-1.10.0-3.el6ost.noarch openstack-swift-1.10.0-3.el6ost.noarch
Updated doc text accordingly.
Hi ppai, Please review the doc text for technical accuracy and sign off.
The doc text meant slightly different from the actual bug fix. Have updated the same.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2014-1278.html