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

Revision as of 15:26, 21 May 2013

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

Context

We want to make a Glance API endpoint public to enable end-user (not admin) upload of images.

Problems Facing a Public Glance Endpoint

Making a Glance API endpoint public causes these problems:

• need some kind of quality control on what's being stuffed into glance as "images"
  • this enhances end-user experience (so you don't keep trying to boot an uploaded movie or something -- want to reject bad images before this point if possible)
• don't want the extra bandwidth, processing requirements of these uploads to interfere with normal glance functionality as an image source for nova
  • want to be able to push the upload, validation process out to the cloud periphery

"Import"

We propose to introduce an end-user upload-type operation called "import".

An objection to this proposal is that Glance v1 has "copy-from" and "location" ... why aren't these sufficient?

Difference between "import" and "copy-from":

• copy-from: you've got an Image (capital "I") to upload
• import: you've got some bits that you want turned into an Image

(In other words, we can trust nova but don't know about ordinary glance "users")

Difference between "import" and "location":

• location: you've got an Image stored elsewhere; glance grabs the bits from there when the Image is requested
• import: you've got some bits stored elsewhere, but there's no way to know whether they are an "Image"

So, for these reasons, we will introduce an import operation.

Example Workflow

Initial Import Request

The initial request would be similar to an image-create, but would be directed to a different path and would return the location of an "image-import" resource.

There are several advantages to using a new resource instead of simply creating an image that could be polled until it turned active:

• if the import is a failure, we don't have to worry about what to do with the image record
• the user's image-list won't be clogged with images that are being imported and can't be used to boot, anyway
• the new resource can be structured to allow for helpful error messages; otherwise, we'd have to try to find a way to shoehorn them into the current image resource
• we can create useful status values for these image-import resources without having to modify the current image statuses

Request 1: POST /v2/image-import
{ "location": "swift://cloud.foo/myaccount/mycontainer/path", <properties>}
Response 1: 201 Created
Location: "http://glance-server/v2/image-import/12345678-1234-1234-1234-123456789abc"

Polling for Import Status

The image-import resource could be polled for import status information. Ultimately, it would contain either the location of the successfully created image or an informative message indicating why the import failed. The ultimate response (either success or failure) would contain an 'Expires-by' field indicating when the image-import resource would be deleted so we wouldn't have these things accumulating indefinitely.

Request 2 - N: GET /v2/image-import/12345678-1234-1234-1234-123456789abc
Response 2 - N-1: 200 OK
{ "status": "importing", ...} or {"status": "verifying", ...} or {"status": "what-have-you"}
Response N: 200 OK
{ "status": "success", "image": "/v2/images/deadbeef-dead-dead-dead-beefbeefbeef", "expires-by": "2013-05-21T15:19:56+0000"}
or
{ "status": "failure", "message": "something very helpful and informative", "expires-by": "2013-05-21T15:19:56+0000"}

Image Retrieval

If the import is successful, the imported image is available through Glance in the normal way:

Request N+1: GET /v2/images/deadbeef-dead-dead-dead-beefbeefbeef
Response N+1: 200 OK
{ "status": "active", ... }