Difference between revisions of "Glance-new-upload-workflow"
| Line 1: | Line 1: | ||
This is the full specification for blueprint:https://blueprints.launchpad.net/glance/+spec/new-upload-workflow | 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 This Introduces === | ||
| + | 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. | ||
Revision as of 14:53, 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 This Introduces
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.
