Difference between revisions of "Glance-new-download-workflow"
(→Open Questions) |
|||
| Line 62: | Line 62: | ||
# When an image-export resource is created for <tt>{imageId}</tt>, we have to make it the case that the image cannot be deleted until the image-export reaches either success or failure status. | # When an image-export resource is created for <tt>{imageId}</tt>, we have to make it the case that the image cannot be deleted until the image-export reaches either success or failure status. | ||
# 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 | # 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 | ||
| − | |||
# What would be appropriate export statuses? | # What would be appropriate export statuses? | ||
#* <code>waiting</code> : image-export request has been received, but Glance (via async worker or whatever) hasn't begun to act upon the request yet | #* <code>waiting</code> : image-export request has been received, but Glance (via async worker or whatever) hasn't begun to act upon the request yet | ||
| Line 70: | Line 69: | ||
#* <code>failure</code> : something went wrong, an exported image will not be created from this export request | #* <code>failure</code> : something went wrong, an exported image will not be created from this export request | ||
#* anything else? | #* anything else? | ||
| + | # So when you put this BP together with the new import BP, we have <tt>GET /v2/image-imports</tt> and <tt>GET /v2/image-exports</tt> ... should we instead have something like <tt>/v2/image-actions</tt> 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 == | == References == | ||
<references /> | <references /> | ||
Revision as of 15:42, 22 May 2013
This is the full specification for blueprint:https://blueprints.launchpad.net/glance/+spec/new-download-workflow
Contents
Motivation
Here's why we want an alternative to the "normal" Glance download workflow:
- want to allow a cloud provider the opportunity to "scrub" or otherwise process an image that's going to be pulled out of that provider's cloud
- they don't have to, but want to make the option available
- want to push all efforts associated with getting images out of the cloud to the cloud periphery so the bandwidth/compute required doesn't affect normal cloud functionality
We propose calling this functionality "export" (to keep symmetry with the proposed new "import" functionality [1])
Example Workflow (API View)
Initial Export Request
The initial request would return the location of an "image-import" resource that could be subsequently polled to determine the status of the export.
Request 1: POST /v2/images/deadbeef-dead-dead-dead-beefbeefbeef/export
{ "some-stuff" : "whatever" }
Response 1: 201 created Location: "http://glance-server/v2/image-exports/12345678-1234-1234-1234-123456789abc"
Polling for Export Status
Request 2 - N: GET /v2/image-exports/12345678-1234-1234-1234-123456789abc
Response 2 - N-1: 200 OK
{ "status" : "waiting", "image_uuid" : "deadbeef-dead-dead-dead-beefbeefbeef" }
Final Result of Export
Response N: 200 OK
{ "status" : "success",
"image_uuid" : "deadbeef-dead-dead-dead-beefbeefbeef",
"location" : "protocol://some-server/path/data",
"expires-by" : "2013-05-21T15:19:56+0000" }
or
{ "status" : "failure",
"image_uuid" : "deadbeef-dead-dead-dead-beefbeefbeef",
"message" : "Some really informative message",
"expires-by" : "2013-05-21T15:19:56+0000" }
The location would be a temp url where the data could be retrieved before the "expires-by" time. The "expires-by" would also specify the expiration of the image-export resource containing the field. The user would do a GET on the temp url and receive application/octet-stream.
Summary
- introduce new resource, 'image-export'
- 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
- 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.
- 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
- 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?
-
- 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!
