Bug 849753 - UFO swift object versioning
UFO swift object versioning
Status: CLOSED ERRATA
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: gluster-swift (Show other bugs)
2.0
Unspecified Unspecified
low Severity low
: ---
: ---
Assigned To: crisbud@redhat.com
pushpesh sharma
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-20 15:05 EDT by Kaleb KEITHLEY
Modified: 2014-08-04 18:30 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-05-26 02:49:44 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kaleb KEITHLEY 2012-08-20 15:05:51 EDT
Description of problem:

umbrella 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:
Comment 2 Kaleb KEITHLEY 2012-09-05 13:53:00 EDT
http://docs.openstack.org/developer/swift/overview_object_versioning.html

Object versioning in swift is implemented by setting a flag on the container to tell swift to version all objects in the container. The flag is the X-Versions-Location header on the container, and its value is the container where the versions are stored. It is recommended to use a different X-Versions-Location container for each container that is being versioned.

When data is PUT into a versioned container (a container with the versioning flag turned on), the existing data in the file is redirected to a new object and the data in the PUT request is saved as the data for the versioned object. The new object name (for the previous version) is <versions_container>/<length><object_name>/<timestamp>, where length is the 3-character zero-padded hexidecimal length of the <object_name> and <timestamp> is the timestamp of when the previous version was created.

A GET to a versioned object will return the current version of the object without having to do any request redirects or metadata lookups.

A POST to a versioned object will update the object metadata as normal, but will not create a new version of the object. In other words, new versions are only created when the content of the object changes.

A DELETE to a versioned object will only remove the current version of the object. If you have 5 total versions of the object, you must delete the object 5 times to completely remove the object.

Note: A large object manifest file cannot be versioned, but a large object manifest may point to versioned segments.
Comment 3 Luis Pabón 2013-07-12 14:52:59 EDT
Need to confirm status of this bug with current RHS2.1 code.
Comment 4 Luis Pabón 2013-07-16 21:00:59 EDT
RHS 2.0 UFO Bugs are being set to low priority.
Comment 5 Prashanth Pai 2014-02-05 10:41:31 EST
This works. Please close.
Comment 6 Prashanth Pai 2014-02-06 00:15:26 EST
This works out of the box. I followed the guide here: http://docs.openstack.org/developer/swift/overview_object_versioning.html

Hence, there are no code changes needed. However, we may have to document this upstream and downstream that object versioning is supported and how one can enable it and use it.

Have tested this in master branch only.
Comment 7 crisbud@redhat.com 2014-02-06 00:17:03 EST
Needs a documentation bug for later releases. Will file one after QE verifies it.
Comment 8 pushpesh sharma 2014-05-08 04:07:15 EDT
This works with RHS2.1 onwards.Tests are also there in functional test suite. Marking it as verified.
Comment 9 Prashanth Pai 2014-05-26 02:49:44 EDT
This bug has been fixed in Corbett.

Note You need to log in before you can comment on or make changes to this bug.