Glance-tasks-clone
This is the full specification for blueprint:https://blueprints.launchpad.net/glance/+spec/clone-image-across-regions
Contents
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.
This operation would make sense as part of the v2 "tasks" API.
Why Clone? Why not just export and then import?
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, since it would already be in the provider-specific format.
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 a task resource that could be subsequently polled to determine the status of the cloning operation.
A clone task request will adhere to the task_request schema described in [1].
Request 1: POST /v2/tasks
{ "type" : "clone",
"input": {
"source_image_url": "http://source-glance.cloud.com/v2/images/deadbeef-dead-dead-dead-beefbeefbeef",
"image_properties" : {
/* may want to override the source metadata if it's inappropriate for the target region */
"whatever": "something",
"autoscale-group": "target-group"
}
}
}
Response 1: 201 created Location: "http://glance-server/v2/tasks/33335678-3333-3333-3333-333356789abc"
(Note: probably return the task resource in the body)
Clone Task Request input Content
(no ordering, just using the numerals to keep count)
- source_image_url: location of the image in a federated glance server (note: will have to return an error if this is not the case)
- image_properties: this would be the json object of properties you can specify on the current image create call; properties specified here would override properties on the source image. Properties not specified here would be copied over from the source image.
Polling for Cloning Status
An clone task response will adhere to the task schema described in [2].
Request 2 - N: GET /v2/tasks/33335678-3333-3333-3333-333356789abc
Response 2 - N-1: 200 OK
{ "type" : "clone",
"status" : "pending",
"input": {
"source_image_url": "http://source-glance.cloud.com/v2/images/deadbeef-dead-dead-dead-beefbeefbeef",
"image_properties" : {
"whatever": "something",
"autoscale-group": "target-group"
}
},
"id": "43215678-4321-4321-4321-432156789abc",
...,
}
Final Result of Clone Action
Response N: 200 OK
{ "type" : "clone",
"status" : "success",
"input": {
"source_image_url": "http://source-glance.cloud.com/v2/images/deadbeef-dead-dead-dead-beefbeefbeef",
"image_properties" : {
"whatever": "something",
"autoscale-group": "target-group"
}
},
"result": {
"target_image_uuid" : "deadbeef-beef-beef-beef-deaddeaddead"
},
"expires_at" : "2013-05-21T15:19:56+0000",
"id": "43215678-4321-4321-4321-432156789abc",
...,
}
or
{ "type" : "clone",
"status" : "failure",
"input": {
"source_image_url": "http://source-glance.cloud.com/v2/images/deadbeef-dead-dead-dead-beefbeefbeef",
"image_properties" : {
"whatever": "something",
"autoscale-group": "target-group"
}
},
"message" : "Some really informative message",
"expires_at" : "2013-05-21T15:19:56+0000",
"id": "43215678-4321-4321-4321-432156789abc",
...,
}
Note: The "expires_at" would specify the expiration of the task resource itself (not the cloned object).
Clone Task Response result Content
- target_image_uuid
Open Questions
- We're assuming that since the source image is housed in a federated glance, there's no need for credentials to be included in the clone task request. Is this assumption reasonable?
- This may require some kind of image locking across two glance instances. With cloning, a user owns both ends of the image transfer 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 already, deleting the image in region S before it is actually copied. I think this is less of a concern now that we've made cloning part of the "tasks" API, because when you make a clone request, you get back a task object, not an image object. I think this makes it pretty clear to the user that the image does not exist yet in the target region. So any kind of locking would only have to occur in the source region, similar to what will have to be done to export an image.
- What about the metadata? We don't plan on offering ongoing sync, but there should be an initial copy.
- need to determine implications for "protected" properties
- do we want to allow the user to specify properties at the time of clone (any properties specified in the request would overwrite properties on the source image), or make the user wait until after success and update the image at that point?
- What would be appropriate clone statuses?
- Do we use the generic task statuses, or do we want to be more specific here? (We could be, but that doesn't mean we have to be!)
- could have something like:
-
pending: a clone task has been created, 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 to target glance -
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 task
-
- anything else?
- How will the Glance-to-Glance communication be handled?
Revison History
This is a revised version of [3]. The revision is mostly to make this part of the tasks API [4].
Revised again 23 Aug 2013 in light of discussion captured in [5].
