Support of MOVE for objects

Registered by Vincent Giersch on 2013-08-15

Currently, the best way to move an object is to execute a COPY followed by a DELETE, which is not very efficient.
The goal of this blueprint is therefore to add the support of the MOVE HTTP method in the Swift API. For an obvious reason of performance, this action will be handled directly by the storage node that
renames the object and sets the correct metas.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Superseded
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Vincent Giersch on 2013-08-16

Related branches

Sprints

Whiteboard

API design:

PUT /a/c/o_moved {X-Move-From: a/c/o}
MOVE /a/c/o {Destination: a/c/o_moved}

Current use case:
client -> PUT a/c/o_moved {X-Move-From c/o} proxy
  proxy -> LINK a/c/o_moved {X-Link-From c/o} storage{1,2}
  proxy <- 2xx storage{1,2}
  proxy -> DELETE a/c/o storage{1,2}
  proxy <- 2xx storage{1,2}
client <- 2xx client

Summary of the patches:

Patches 1 & 2: First implementation. The proxy server implemented a MOVE method in a similar way to COPY, and called a MOVE method on the Swift Object server. The major problem was to have the objects recorded at least twice in the containers, which was not guarantee.

Patches >= 3: Update using hard links: The proxy calls a LINK action on the object server that creates a new object using a hard link to the old object, then calls DELETE on the old object.

Gerrit topic: https://review.openstack.org/#q,topic:bp/swift-move,n,z

Open Questions:

Should the account be included in the X-Move-From (different from COPY)?
How will ACL authorization be enforced at the target location?
What if the new name hashes to a partition on a different node?

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.