Open Stack

-----Original Message-----
From: Ian Cordasco <ian.cordasco at rackspace.com>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: January 8, 2016 at 11:16:35
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject:  [openstack-dev] [API] [Glance] New v2 Image Import Specification	Discussion

[snip]  
> So what if we modeled this a little
>  
> 1. The user creates an image record (image-create)
> 2. The user uses the link in the response to upload the image data (we don't care whether  
> it is direct or not because the user can follow it without thinking about it)
> 3. The user sends a request to process the image without having to specify what to translate  
> the image to because the operator has chosen a preferred image type (and maybe has other  
> acceptable types that mean the image will not need to be converted if it's already of that  
> type).
>  
> This adds an extra step and it could remove the need for an "uploading" status.
>  
> This also means that the user does not need to be cognizant of the method that they're using  
> to create an image (glance-direct, swift-local, foo-bar-bogus-whatever, etc.) and  
> that they do not need to think too hard about the target format for that cloud or pre-process  
> any extra information or worry whether that cloud needs some location URL for an indirect  
> upload. Glance can manage that complexity for the user.
>  
> Now let's talk about step 2 briefly. If the operator wants all image bytes to go to Glance  
> directly, this can be the default behaviour. In that case, the URL would be "https:///v2/images//files"  
> and the user would do it like the default PUT behaviour that we have now. If it's an indirect  
> upload, then the user would make another PUT request with that URL and their authentication  
> credentials. If the user is out of storage quota than that service will tell the user.  
>  
> I think in this way, we can provide the user some information about their uploaded data  
> as well as well as letting admins handle quota. This still doesn't discuss giving admin  
> more visibility (in a direct upload case) about quota of uploaded but not yet processed  
> data. That's an important question to have, but I don't have an easy answer for it though.  
> I hope someone else does.

So one edge case/snag in this workflow is the following:

Once an image is in the "active" state, what happens to the URL that is returned as part of the image representation for where to upload data?

I don't think we want to have an attribute that disappears once an image becomes active. I think it would make sense to return `null` in that case, but I'd like to hear other people's thoughts.

Also, to prevent questions, I do envision that before an image is processed that the user could upload several times (overwriting each time) the image data to the same resource. Hopefully that makes sense to everyone. (This is identical to what's being proposed in the current spec.)

--  
Ian Cordasco