Bug 1041591 - [RFE][swift]: Support for append-only Swift objects
Summary: [RFE][swift]: Support for append-only Swift objects
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: RFEs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact:
URL: https://blueprints.launchpad.net/swif...
Whiteboard: upstream_milestone_none upstream_stat...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-12 18:07 UTC by RHOS Integration
Modified: 2015-03-19 17:40 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-19 17:40:48 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description RHOS Integration 2013-12-12 18:07:59 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/swift/+spec/object-append.

Description:

Support for append-only objects.
This is just an optimization for PUT->GET->PUT or PUT->GET->DELETE->PUT for existing objects.
Instead of sending a new object each time to overwrite the old one, the end-user can just send the difference in HTTP request.

Current flow for PUT is as follows:
- create temp file
- write user data into temp file
- check temp file for consistency (if possible)
- rename temp file to a timestamp
- delete old file (with old timestamp)
- update file metadata (in xattrs)

Proposed flow for append:
- lock the original file for append
- write user data into file
- check file for consistency (if possible)
- unlock file
- rename old file to new timestamp
- update revision data (in xattrs)
- update file metadata (in xattrs)

Concurrent append will be impossible (but it's not needed in most cases)
All replication/async update logic will stay the same.
The end result will be no different from PUT on existing file.

But, there will be some logic changes in object server behavior:
- file size have to be stored and retrieved from metadata only
- if file is actually bigger than its size (from metadata) it should be left alone and not quarantined
- new xattr entity have to be added to store the file revisions (should be stored in extents, not in inode)
- revision data should store: revision number, size and md5 state (maybe also the timestamp)
- md5 state should be clawed out from hashlib (not that hard)
- append should be embedded in POST and not in PUT request


Specification URL (additional information):

None


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