-----Original Message----- From: Ian Cordasco <ian.corda...@rackspace.com> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Date: January 8, 2016 at 11:16:35 To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
