Jump to: navigation, search

Difference between revisions of "Glance-new-download-workflow"

(Open Questions)
Line 1: Line 1:
This is the full specification for blueprint:https://blueprints.launchpad.net/glance/+spec/new-download-workflow
{{Note|Superceded|This document has been superceded by https://wiki.openstack.org/wiki/Glance-tasks-export}}
The related blueprint is https://blueprints.launchpad.net/glance/+spec/new-download-workflow
== Motivation ==
== Motivation ==

Latest revision as of 15:44, 25 July 2013

Tango-Software-update-urgent.svg This document has been superceded by https://wiki.openstack.org/wiki/Glance-tasks-export

The related blueprint is https://blueprints.launchpad.net/glance/+spec/new-download-workflow


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" }
{ "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.


  • 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

  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!


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