Open Stack

Hi Jay and Mark.  I think Mark answered some of your concerns, I'll try to
address the rest.  Comments are inline.  Thanks for the discussion!
________________________________________
> On 05/22/2013 06:14 PM, Jay Pipes wrote:
> 
> Hi Mark, comments inline. Thanks!
> 
> On 05/22/2013 05:57 PM, Mark Washenberger wrote:
> > On Wed, May 22, 2013 at 1:50 PM, Jay Pipes <jaypipes at gmail.com
> <snip>
> >
> >     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.
> 
> Same with images that are in the process of being uploaded... there's no
> substantive difference between an "image import" and simply uploading an
> image.

One substantive difference is the source of the image.  When the image is coming
from nova as a snapshot, or being uploaded by an admin after QA testing, we're
assured of a bootable image and can just use the current upload process.  So I'm
thinking of upload being used for intra-cloud purposes.  For import, we're talking
about receiving an image from a source external to the cloud, whether a different
cloud or a home-brewed user image, so I think it makes sense to allow for different
processing to occur before the image is put into Glance, e.g., maybe image format
conversion or maybe some kind of security scan, something like that.  So there
seem to be more points of failure possible in an import, and maybe it's not a good
idea to create an Image in Glance until we're sure we've actually got something
that's bootable in this particular cloud.

> > 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-regions
> > and https://blueprints.launchpad.net/glance/+spec/iso-image-metadata).
> > So the image is still very much in flux.
> 
> This still doesn't mean a whole new REST resource is necessary or that
> the workflow is any different from the current image upload flow.

I agree that a new REST resource isn't necessary in the strict sense of the term,
but the implications of using the current Image resource in this context is that
we should add more statuses, or add a task_state, or both, and also add some
way to convey error information to the user.  But these extra statuses or
task_states are more closely aligned with the import operation than with the
Image itself.  In upload, the Image is used as a resource you can poll until
it's ready for use, and since there's a high probability that it will go active, that
seems OK.  But with import, there seem to be more problems that could happen,
and I like the idea of a pollable resource (with an expiration date, so we can
hard-delete them!) that's specifically designed for the purpose of monitoring an
import (or export, or trans-region image cloning operation).  I think it would
make for a better user experience to keep these resources separate.

> > 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.
> 
> I don't understand this. The verification process doesn't change the
> bits of the image, so why would the checksum change?

This is my fault, Jay.  I had this in my head from the summit
discussions, but didn't state it clearly in the document you read.  An
important use case for import (as mentioned above) would be when
some kind of conversion has to be done on the image, e.g., user
uploads an image in a format different from what the cloud provider
uses.  I think it makes for a better user experience for the conversion
to happen during import, rather than store the Image as it is in Glance
and then convert just before boot.  My preference is to fail fast in this
case so that the user is never under the impression that she's got a
useable image when that's not the case.  Anyway, to specifically
address your point, that's how checksum and other relevant properties
might change during import.

> > 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.
> 
> Now this, I totally understand. That said, I don't believe the proposed
> new top-level /image-imports resource is the appropriate way to deal
> with this. I could, on the other hand, get behind a proposal to, say,
> add a new /images/<UUID>/faults subcollection resource that could be
> queried for an image.

I guess it depends on what kind of faults we have in mind.  I'm thinking of
the possibility of non-recoverable faults, and then it doesn't seem to make
sense to have an Image that's got a fault subresource that means it will
never really be an Image.  But that's just me.

> > 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?"
> 
> I don't buy this argument :) It's as simple as adding a new image status
> (Verifying) and changing the couple lines of code that currently handle
> state change between image statuses...

Well, we could do it the way you suggest, Jay, but we're speaking in the context
of Glance becoming a full-fledged member of the OpenStack ecosystem.  So
normal cloud users will be interacting with Glance directly instead of being
proxied through Nova.  So with respect to user experience, if we stick with
the Image as the resource, users will try to do image-type stuff (delete, modify,
share, etc.) with an Image that isn't ready yet, and then find out they can't by
getting an error response.  On the other hand, if you don't even have an Image
to work with, you don't expect to be able to do image-type-stuff with it.  Now,
you're right, we could ask them to RTFM and understand that an Image in
"verifying" status can't be used for x, y, z, but I think an image-import resource
makes this more obvious.

> > 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.
> 
> But we already have this... if an image is currently uploading, its
> status is "Saving". Users won't see these images in their GET /images
> responses until the image gets to Active status. It's the same concept
> for the Verifying status here.
> 
> > 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).
> 
> Perhaps I'm just not understanding this because I missed all the Glance
> sessions at the summit :( But the above kinda sounds like Glance
> development is heading towards shattering the up-to-now-set-in-stone
> dictate that once an image is uploaded and active, it is immutable.
> 
> Has that dictate changed with this new import/export stuff?

I'm sorry you missed the sessions too, they were great, and we missed
your input.  No, the dictate hasn't changed, we're just talking about a
different use case here.  The Image in Glance, uploaded and active, is still
immutable (although it's metadata can still change), it's just that the use case
we're focused on is really image portability, so users can make a snapshot
of an instance in one cloud, move it to a different cloud, and boot an instance
there.  So the Image in Glance in cloud A is immutable, but if you just
dropped it into cloud B, it might not be bootable.  Thus a user might want to be
able to export in a neutral format and a cloud provider might want to make this
possible.  Likewise, a cloud provider might want to accept the import of an
image that is not bootable-as-is in that provider's cloud; the actual thing
stored after the import process, however, would be bootable and immutable.

> Best,
> -jay

Thanks Jay, hope this helps answer your questions!

cheers,
brian