Difference between revisions of "Glance-image-cloning"

Latest revision as of 05:01, 3 June 2013

This is the full specification for blueprint:https://blueprints.launchpad.net/glance/+spec/clone-image-across-regions

This is clearly at the proposal stage, nothing is set yet.

Motivation

Many Cloud providers have clouds in segregated "regions". AWS just announced the ability for customers to copy images to other regions -- we want to implement the same capability in OpenStack.

We're just looking at what the API would look like here, not the infrastructure to support the functionality.

Vocabulary

• "source" region: where the image is now
• "target" region: where you want the image copied to

Example Workflow (API View)

Initial Clone Request

We're proposing a "pull" model, i.e., the cloning request would originate in the target region. The initial request would return the location of an "image-action" resource that could be subsequently polled to determine the status of the cloning operation.

(We're proposing an "image-action" resource that could be used for image cloning, image import^[1], and image export^[2]. If you don't like that idea, replace "image-action" and "image-actions" with "image-clone" and "image-clones" below.)

Request 1: POST /v2/image-actions
{ "action_type" : "clone",
  "source_region": "???need to figure out how to represent this ... or just require full URL below? ???",
  "source_image_url": "http://source-glance.cloud.com/v2/images/deadbeef-dead-dead-dead-beefbeefbeef" }

Response 1: 201 created
Location: "http://glance-server/v2/image-actions/12345678-1234-1234-1234-123456789abc"

Polling for Cloning Status

Request 2 - N: GET /v2/image-actions/12345678-1234-1234-1234-123456789abc

Response 2 - N-1: 200 OK
{ "action_type" : "clone",
  "status" : "waiting" (or whatever),
  "source_region": "something",
 "source_image_url": "http://source-glance.cloud.com/v2/images/deadbeef-dead-dead-dead-beefbeefbeef" }

Final Result of Clone Action

Response N: 200 OK
{ "action_type" : "clone",
   "status" : "success",
  "source_region": "something",
  "source_image_url": "http://source-glance.cloud.com/v2/images/deadbeef-dead-dead-dead-beefbeefbeef",
  "cloned_image_uuid" : "deadbeef-beef-beef-beef-deaddeaddead",
  "expires-by" : "2013-05-21T15:19:56+0000" }
or
{ "action_type" : "clone",
   "status" : "failure", 
  "source_region": "something",
  "source_image_url": "http://source-glance.cloud.com/v2/images/deadbeef-dead-dead-dead-beefbeefbeef",
  "message" : "Some really informative message",
  "expires-by" : "2013-05-21T15:19:56+0000" }

The "expires-by" would specify the expiration of the image-action resource itself.

Summary

• introduce new resource, 'image-action'
  • the resource will need to have an "owner" field (whether or not it's exposed in the response) so that we can make sure that users can't see each other's action requests
  • should implement a GET /v2/image-actions that would respond with a list of all image-actions that exist for this user
    • would allow filtering by type, e.g., ?action_type=clone
  • define JSON schema for 'image-action' request with action_type "clone"
  • define JSON schema for 'image-action' response with action_type "clone"
    • enumerate 'status' values
  • define POST for 'image-action'
  • define GET for 'image-action'

[ still working on the below! it's copied from a different BP, need to make changes ]

Open Questions

1. Maybe I'm being stupid here, but I think this is different from an import. With an import, you know you're getting the image from somewhere else, so if it disappears, that's not surprising. With cloning, you own both ends of the transaction, and I'm worried about someone starting a cloning action in region T from region S, and then, figuring that they've got a clone, deleting the image in region S before it is actually copied. So the cloning operation should "lock" (more like "make-non-deletable") the image in region S, similar to what's proposed for image-export. We definitely don't want to make the clone request wait on a response from the Glance in the other region, though. Maybe this isn't a big concern? Please talk me out of it!
2. OK, just remembered the big reason cloning is different from import/export: in the cloning situation, we have federated glances (e.g., same cloud provider but different regions). This makes possible a backend-to-backend transfer mediated by glance, which I think would be really cool. Also there would be no need to scrub/validate the cloned image.
3. What about the metadata? We don't plan on offering ongoing sync, but there will be an initial copy ... if we're assuming that the glances are federated somehow, they may (will?) have the same protected properties, guess we should transfer those too? Or do we have a cloning whitelist (or blacklist) at the export point?
4. What would be appropriate clone statuses?
   • waiting : clone request has been received, but target Glance (via async worker or whatever) hasn't begun to act upon the request yet
   • preparing : target Glance has contacted source Glance and received an ack that the image exists in source region and is eligible for cloning
   • transferring : data is being moved
   • success : data has been transferred to the location specified in the response
   • failure : something went wrong, a local image will not be created from this clone request
   • anything else?

References

1. ↑ https://wiki.openstack.org/wiki/Glance-new-upload-workflow
2. ↑ https://wiki.openstack.org/wiki/Glance-new-download-workflow