Jump to: navigation, search

Glance-image-cloning

Revision as of 21:08, 22 May 2013 by Brian-rosmaita (talk | contribs) (Created page with "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 ye...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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-clone" resource that could be subsequently polled to determine the status of the cloning operation.

Request 1: POST /v2/image-actions
{ "action" : "clone",
  "source_region": ???,
  "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-exports/12345678-1234-1234-1234-123456789abc
Response 2 - N-1: 200 OK
{ "status" : "waiting",
   "source_image_url": "http://source-glance.cloud.com/v2/images/deadbeef-dead-dead-dead-beefbeefbeef" }

Final Result of Export

Response N: 200 OK
{ "status" : "success",
  "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
{ "status" : "failure", 
  "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 containing the field.

[ below here still needs a rewrite ! ]


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 export requests
    • should implement a GET /v2/image-exports that would respond with a list of all image-exports that exist for this user
    • define JSON schema for 'image-export' request
    • define JSON schema for 'image-export' response
      • enumerate 'status' values
    • define POST for 'image-export'
    • define GET for 'image-export'

Open Questions

  1. When an image-export resource is created for {imageId}, we have to make it the case that the image cannot be deleted until the image-export reaches either success or failure status.
  2. The initial export request could include a 'location' to which the export would be done, including credentials on that url. Might be best just to go with the temp url for the first implementation
  3. What would be appropriate export statuses?
    • waiting : image-export request has been received, but Glance (via async worker or whatever) hasn't begun to act upon the request yet
    • processing : Glance is doing some work (scrubbing or whatever)
    • transferring : data is being moved (or should we just let this be part of "processing"?)
    • success : data has been transferred to the location specified in the response
    • failure : something went wrong, an exported image will not be created from this export request
    • anything else?
  4. So when you put this BP together with the new import BP, we have GET /v2/image-imports and GET /v2/image-exports ... should we instead have something like /v2/image-actions that would list all the non-expired actions you had going? We could then have a single resource type, 'image-action', which would include an "action_type" (either "import" or "export"). This image-actions-list call could allow for filtering by action_type.
    • I'm starting to think image cloning to other regions should create a new resource (image-clone) like image-export or image-import, so I like this idea!

References