Jump to: navigation, search

Glance-tasks-export

Revision as of 19:48, 23 July 2013 by Brian-rosmaita (talk | contribs) (Export Task Response Properties)

This is the full specification for blueprint:https://blueprints.launchpad.net/glance/+spec/new-download-workflow

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

"Export"

We propose to introduce as a Glance task an end-user download-type operation called export.

The arguments in favor of an "import" operation also apply to "export", so they're not repeated here. See the Import specification [1] for more information.

Example Workflow (API View)

Initial Export Request

The initial request would be directed to the tasks path and will return the location of task resource that can be subsequently polled to determine the status of the export.

Request 1: POST /v2/tasks
{ "task_type": "export",
  "image_uuid": "deadbeef-dead-dead-dead-beefbeefbeef",
  "export_to": "swift://cloud.foo/myaccount/mycontainer/path",
  "export_format": "qcow2",
  "export_to_credentials": {
    /* ??? */
  }
}

Alternative: could make a POST to /v2/images/deadbeef-dead-dead-dead-beefbeefbeef/export

Response 1: 201 created
Location: "http://glance-server/v2/tasks/43215678-4321-4321-4321-432156789abc"

(Note: probably return the task resource in the body)

Export Task Request Properties

(no ordering, just using the numerals to keep count)

  1. task_type: export
  2. image_uuid: the image to export
  3. export_to: url for glance to write to
  4. export_format: image format to write
  5. export_to_credentials: credentials allowing glance to write to the export_to url (but see Open Question, below, about this)

Polling for Export Status

Request 2 - N: GET /v2/tasks/43215678-4321-4321-4321-432156789abc
Response 2 - N-1: 200 OK
{ "task_type": "export",
  "task_status" : "waiting",
  "image_uuid" : "deadbeef-dead-dead-dead-beefbeefbeef",
  "export_to": "swift://cloud.foo/myaccount/mycontainer/path",
  "export_format": "qcow2",
  "id": "43215678-4321-4321-4321-432156789abc",
   ..., 
}

Export Task Response Properties

(no ordering, just using the numerals to keep count)

  1. id
  2. owner
  3. task_type: export
  4. task_status
  5. image_uuid: the image to export
  6. export_to: url for glance to write to
  7. export_format: image format to write
  8. export_location: URI of the successfully exported image
  9. expires_at
  10. message

(Note: we'll have to maintain the credentials, even though they're not included in the response)

Final Result of Export

Response N: 200 OK
{ "task_status" : "success",
  "image_uuid" : "deadbeef-dead-dead-dead-beefbeefbeef",
  "export_location": "swift://cloud.foo/myaccount/mycontainer/path/12345678-abcd-abcd-abcd-987654321abc",
  "export_format": "qcow2",
  "expires_at" : "2013-05-21T15:19:56+0000",
  "id": "43215678-4321-4321-4321-432156789abc",
   ...,
}
or
{ "task_status" : "failure", 
  "image_uuid" : "deadbeef-dead-dead-dead-beefbeefbeef",
  "message" : "Some really informative message",
  "expires_at" : "2013-05-21T15:19:56+0000",
  "id": "43215678-4321-4321-4321-432156789abc",
   ..., 
}

In this example, the "export_to" field indicated a location where the user had write privileges (how do we handle credentials?). Alternatively, it could be a temp url where the data could be retrieved before the "expires_at" time; the user would do a GET on the temp url and receive application/octet-stream. The "expires_at" would also specify the expiration of the task resource containing the field.

To Do

  • define JSON schema for export tasks request
  • define JSON schema for export tasks response
    • enumerate 'task_status' values for export

Open Questions

  1. When an task resource is created for {imageId}, we have to make it the case that the image cannot be deleted until the export task reaches either success or failure status.
    • Do we need an image task_state like instances have?
  2. Need to decide how credentials will be supplied for the "export_to" location, or we could just go with the temp url in the success response for the first implementation
  3. What's the best URI to use for the POST operation? Here are a few choices:
    • /v2/tasks
      • Pro: symmetry with import, clone; Con: doesn't make use of the fact that we have an existing image to export
    • /v2/images/UUID/export
      • Pro: makes use of existing image resource; Con: we're not really creating an "export" resource at this URI.
    • /v2/images/UUID/tasks
      • Pro: makes use of existing image resource; Con: we are creating a "task", but not at this URI. Guess you could create a task object at this URI, e.g., /v2/images/IMAGE-UUID/tasks/TASK-UUID, but then you lose the ability to do a GET /v2/tasks to list all your current tasks.
  4. What would be appropriate export statuses?
    • queued : an export task has been created, 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?

Revison History

This is a revised version of [2]. The revision is mostly to make this part of the tasks API [3].

References

  1. https://wiki.openstack.org/wiki/Glance-tasks-import
  2. https://wiki.openstack.org/wiki/Glance-new-download-workflow
  3. https://wiki.openstack.org/wiki/Glance-tasks-api