<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 22, 2013 at 1:50 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 05/22/2013 12:35 PM, Brian Rosmaita wrote:<br>

> Hello all,<br>
><br>
> 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:<br>
><br>
> BPs:<br>
> <a href="https://blueprints.launchpad.net/glance/+spec/new-upload-workflow" target="_blank">https://blueprints.launchpad.net/glance/+spec/new-upload-workflow</a><br>
> <a href="https://blueprints.launchpad.net/glance/+spec/new-download-workflow" target="_blank">https://blueprints.launchpad.net/glance/+spec/new-download-workflow</a><br>
><br>
> Full specs:<br>
> <a href="https://wiki.openstack.org/wiki/Glance-new-upload-workflow" target="_blank">https://wiki.openstack.org/wiki/Glance-new-upload-workflow</a><br>
> <a href="https://wiki.openstack.org/wiki/Glance-new-download-workflow" target="_blank">https://wiki.openstack.org/wiki/Glance-new-download-workflow</a><br>
<br>
</div>I don't really see the need to add a whole new workflow and API resource<br>
for this.<br>
<br>
Why not just add the new status called "Verifying" and then place images<br>
that are done with the "Saving" state into this "Verifying" state until<br>
someone (or something) calls:<br>
<br>
PUT /images/<UUID><br>
<br>
with a body of:<br>
<br>
{<br>
 'status': 'ACTIVE'<br>
}<br>
<br>
You can use the existing policy stuff to enforce that only users with<br>
certain privileges can change an image's status from Verifying to<br>
Active, and images never show up in a user's list of images (public or<br>
otherwise) until they are in ACTIVE state anyway.<br>
<br>
For images added to Glance with copy_from or location, simply change the<br>
current behaviour of setting the image status to Active after the image<br>
has been copy_from'd instead to Verifying.<br>
<br>
This way, there's no need to introduce a new /image-imports resource at<br>
all, and you don't change the image retrieval workflow at all.<br>
<br>
Best,<br>
-jay<br>
<div class=""><div class="h5"><br>
</div></div></blockquote></div><br></div><div class="gmail_extra" style>Hi Jay,</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>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.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>1) Before import is done, you really can't use the image for anything. </div><div class="gmail_extra" style>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 <a href="https://blueprints.launchpad.net/glance/+spec/clone-image-across-regions">https://blueprints.launchpad.net/glance/+spec/clone-image-across-regions</a> and <a href="https://blueprints.launchpad.net/glance/+spec/iso-image-metadata">https://blueprints.launchpad.net/glance/+spec/iso-image-metadata</a>). So the image is still very much in flux.</div>
<div class="gmail_extra" style>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.</div>
<div class="gmail_extra" style>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.</div>
<div class="gmail_extra" style>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?"</div><div class="gmail_extra" style>
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.</div><div class="gmail_extra" style>
<br></div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>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).</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>Thanks for your feedback! And thanks to Rosmaita for putting these documents together!</div><div class="gmail_extra" style>
markwash </div><div class="gmail_extra" style><br></div></div>