Open Stack

Thanks for the detailed feedback, Brian, much appreciated. Followup
comments inline :)

On 05/24/2013 11:42 AM, Brian Rosmaita wrote:
>> On 05/22/2013 06:14 PM, Jay Pipes wrote:
>> 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.

I still think this is just describing a state-change for an image, not a
whole new resource.

Put another way, if you try to boot an instance in Nova and it fails to
boot for some reason, does it cease to be an instance? No... of course
not, it just is an instance in an error state.

In the use cases you've described here and below, I see those use cases
as expanding the lifecycle of the same Image resource -- adding some
possible state transitions to the lifetime of an Image. In the same way
that pause/unpause adds new state transitions to an instance in Nova, I
believe all we are talking about here is an additional two image state
transitions: one for "verifying" and another possible one for
"converting", the latter one describing the use case of an image being
converted to another format.

>>> 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.

I actually am of the opinion that keeping the resource the same (images)
and adding additional task_states is more user-friendly. You are still
polling on a condition -- an image going from saving to active status,
an image going from saving to verifying state, or an image going from
pending_delete to deleted status.

I feel that adding a new resource when it is actually a new set of state
transitions for the same image resource actually makes the API more
complex than it needs to be. I see your point, I just happen to disagree :)

>>> 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.

OK, I understand how the checksum can change in the above use case --
then again, it seems like the explicit policy is that an image's
checksum shall not change unless it experiences a state transition from
converting to active. Which again goes to my point about keeping
everything in the same resource, but with additional task_states/statuses...

>>> 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.

Well, as I mention above, if an instance in Nova fails to boot because
of some error, it's still an Instance. :) It just happens to be in an
error state. I see the same being true for images that transition to an
error state -- they are still images.

>>> 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.

But this isn't true, even now. Users cannot share an image that isn't in
an active status. As for deletion, users can only delete images that are
not in a killed or pending_delete status. Nothing about an image
verification or image conversion process would change these policies.

> 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.

I understand your point, but I just disagree. I think you would be
asking users to understand a whole new related image-import resource
rather than asking the users to learn an addition to the normal image
life cycle.

<snip>

>>> 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.

:) I wish I could have been there. I was in the QA track for the first
three days of the summit!

>  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), 

Sure, understood.

> 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.

Understood. I get it. But I still stand by my opinion that this is best
handled with the images/ resource and additional state transitions.

Sorry for being stubborn :)

-jay