Open Stack

On Wed, May 22, 2013 at 1:50 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> On 05/22/2013 12:35 PM, Brian Rosmaita wrote:
> > Hello all,
> >
> > Anyone interested in the new upload/download workflow, please take a
> look at the full specs of the new blueprints so we can discuss at
> tomorrow's meeting:
> >
> > BPs:
> > https://blueprints.launchpad.net/glance/+spec/new-upload-workflow
> > https://blueprints.launchpad.net/glance/+spec/new-download-workflow
> >
> > Full specs:
> > https://wiki.openstack.org/wiki/Glance-new-upload-workflow
> > https://wiki.openstack.org/wiki/Glance-new-download-workflow
>
> I don't really see the need to add a whole new workflow and API resource
> for this.
>
> Why not just add the new status called "Verifying" and then place images
> that are done with the "Saving" state into this "Verifying" state until
> someone (or something) calls:
>
> PUT /images/<UUID>
>
> with a body of:
>
> {
>  'status': 'ACTIVE'
> }
>
> You can use the existing policy stuff to enforce that only users with
> certain privileges can change an image's status from Verifying to
> Active, and images never show up in a user's list of images (public or
> otherwise) until they are in ACTIVE state anyway.
>
> For images added to Glance with copy_from or location, simply change the
> current behaviour of setting the image status to Active after the image
> has been copy_from'd instead to Verifying.
>
> This way, there's no need to introduce a new /image-imports resource at
> all, and you don't change the image retrieval workflow at all.
>
> Best,
> -jay
>
>
Hi Jay,

You bring up good points. In some of the design discussion we considered
something similar to what you proposed as well. The intentions behind
making imports a separate action is basically that the image doesn't really
exist until the import is completed. There are a couple of reasons why this
"feels right" to me.

1) Before import is done, you really can't use the image for anything.
2) During the import process, the image may take on additional metadata,
either at a deployers discretion with verification, or based on an
examination of metadata associated with the import source. (I'm thinking of
the use cases from
https://blueprints.launchpad.net/glance/+spec/clone-image-across-regionsand
https://blueprints.launchpad.net/glance/+spec/iso-image-metadata). So the
image is still very much in flux.
3) You probably need to specify a checksum for the data you're uploading to
an import job, but that checksum is unlikely to match the one that is set
on the image when it is done importing. That breaks a certain put/get
parity in an icky way. The same goes for image size, disk and container
format, and other relevant properties.
4) During the import/verify, there will likely be a lot of failures. It
would be better if we have a good way to explain what went wrong with the
failure, but I'd prefer not to add a generic "image_faults" resource. It is
better IMO to track the fault directly along with an entity that represents
the action that failed. I imagine it will be difficult to find a place to
put fault messages inside current image metadata.
5) By having import jobs as a separate resource, we never have to bother
with questions like "Can I delete/modify/share an image during
import/verify/error?"
6) For me, I'd rather not see proper images and image data that is
currently being imported (or recently failed to be imported) in the same
list. Though I expect others would have different preferences.


Regarding image retrieval, I think there is a genuine difference between
export and download. The idea behind download is "give me the bits exactly
as you have them", whereas with export, the idea is more like "save the
image over there in a storage area I can control (say, my swift container)
in a canonical form I can use in other clouds." So interoperability stories
in the future are more geared towards imports and exports, and not uploads
and downloads. At least, that's where we were leaning after the recent
design summit talks about image interoperability (IIRC).


Thanks for your feedback! And thanks to Rosmaita for putting these
documents together!
markwash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130522/7f0fe461/attachment.html>