Glance-image-cloning

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, and image export. 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_image_url": "http://source-glance.cloud.com/v2/images/deadbeef-dead-dead-dead-beefbeefbeef" }

Final Result of Export

Response N: 200 OK
{ "action_type" : "clone",
   "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
{ "action_type" : "clone",
   "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 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. When an image-action 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!