Merge lp:~gholt/swift/lobjects5 into lp:~hudson-openstack/swift/trunk
Status: | Merged |
---|---|
Approved by: | Chuck Thier |
Approved revision: | 152 |
Merged at revision: | 158 |
Proposed branch: | lp:~gholt/swift/lobjects5 |
Merge into: | lp:~hudson-openstack/swift/trunk |
Diff against target: |
81 lines (+51/-9) 2 files modified
swift/proxy/server.py (+9/-9) test/unit/proxy/test_server.py (+42/-0) |
To merge this branch: | bzr merge lp:~gholt/swift/lobjects5 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Chuck Thier (community) | Approve | ||
John Dickinson | Approve | ||
Review via email: mp+44794@code.launchpad.net |
Commit message
Change copies of x-object-manifest objects to copy the actual contents of the object, not just the manifest marker itself.
Description of the change
Change copies of x-object-manifest objects to copy the actual contents of the object, not just the manifest marker itself. In this way, you can consolidate the segments of a manifest object into a single whole object, assuming it meets the max-object-size limitations of the cluster.
This seems to be controversial. I'll let others chime in on their views. Here's my explanation:
A copy of a manifest could really do any of the following:
A) just make a new manifest pointing to the same segments
B) make a new object with the same contents as the source object (ignoring that it's a manifest)
C) make a new manifest pointing to newly made copies of the segments
My logic for picking B is:
A) is really easy/cheap to do client-side
B) is expensive to do client-side and would actually be useful if done server-side
C) is crazy
seems good to me