<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Hi Paul,<br>
<br>
There wasn't a follow up on the mailing list (actually, I guess this is it!). Basically, we discussed Jay's points in the glance meetings and on irc, and decided to stick with this approach. I think the final exchange in that thread sums it up, he understands
why we're proposing to do it this way, but he disagrees. We certainly respect his opinion, and appreciate the extra scrutiny on the proposal, but when it comes down to it, I think there are more advantages than disadvantages to introducing a "task" resource.<br>
<br>
Briefly,<br>
<br>
1. It's better to introduce a new resource that's specifically designed to track task states and deliver clear and specific error messages than to mess with the image resource to get these things onto it.
<br>
<br>
2. The "export" task in particular would require a new resource anyway. I guess you could just enhance the image response and use that, but then you'd have two sets of states on it, the state of the image itself and the state of the export task, and that just
seems confusing. So if we're going to introduce something new for the export task, it's worth considering whether the new resource would be useful for other similar operations.<br>
<br>
3. Having a task resource can allow cancelling the task by deleting it. Otherwise, you're in the position of deleting an image that doesn't really exist yet (in the case of import and clone). Again, you could do this without a new resource, but it just feels
weird to me.<br>
<br>
4. Jay's nova analogy: an instance in error state is still an instance, so an image that fails to import or clone correctly is still an image. I'll pull a lawyer move here and say that (a) i don't think it's a good analogy, and (b) even if it is a good analogy,
it's not a good argument. So for (a), with instances, the provider has to get the instance provisioned, it's taking up resources on the host, etc. With an image import, we don't really have to tie up similar resources before we know that the import or clone
is going to succeed. So while a broken instance is still an instance, we don't have to allow broken images to be images. But also (this is (b)), customers get their knickers in a twist over broken instances, they don't like them, it's not a good experience
to create an instance and have it go to error state and have to be deleted. Rather than give them the same experience with an image import/clone, i.e., wait for the image to go to error state and then have to delete it, we can let the task go to error state
and give them a good error message, and they don't have the frustration of dealing with a bad image. Of course, they have the frustration of dealing with a failed task, but I think that's a big difference.<br>
<br>
5. Following up on that, I like the separation of tasks and images with respect to a user listing what they have in their account. You could do a similar thing by clever filtering of an image-list, but I don't see the point. We've got tasks that may result
in images (or in successful export of an image), and we've got images that you can use to boot instances. I know this is a matter of opinion, but it just seems to me that tasks and images are clearly conceptually different, and having an image resource *and*
a task resource reflects this in a non-confusing way.<br>
<br>
Anyway, this has gotten long enough. Thanks for kicking off the new discussion!<br>
<br>
cheers,<br>
brian<br>
<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF72983"><font size="2" color="#000000" face="Tahoma"><b>From:</b> Paul Bourke [pauldbourke@gmail.com]<br>
<b>Sent:</b> Thursday, August 01, 2013 11:21 AM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] [Glance] images tasks API -- final call for comments<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">
<div>
<div>Hi Brian,<br>
<br>
</div>
I had a read over the summary wiki page and the individual docs. <br>
<br>
My main thought was that although the asynchronous nature seems attractive, the problems the new API is setting out to solve could be adapted to the existing images API. This view seems to be shared and well highlighted by Jay in this thread:
<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-May/009527.html" target="_blank">
http://lists.openstack.org/pipermail/openstack-dev/2013-May/009527.html</a><br>
<br>
</div>
Was there any follow up to that mail? (sorry if I missed it!)<br>
<div><br>
</div>
<div>Thanks,<br>
</div>
<div>-Paul<br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 30 July 2013 19:36, Brian Rosmaita <span dir="ltr"><<a href="mailto:brian.rosmaita@rackspace.com" target="_blank">brian.rosmaita@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
After lots of discussion, here are the image import/export/cloning blueprints unified as a tasks API. Please reply with comments!<br>
<br>
Take a look at this doc first:<br>
<a href="https://wiki.openstack.org/wiki/Glance-tasks-api" target="_blank">https://wiki.openstack.org/wiki/Glance-tasks-api</a><br>
It's got a "related documents" section with links to the previous proposals and also to the earlier email list discussion. It's also got links to the details for the import, export, and cloning tasks, which I guess I might as well paste here so you have 'em
handy:<br>
<a href="https://wiki.openstack.org/wiki/Glance-tasks-import" target="_blank">
https://wiki.openstack.org/wiki/Glance-tasks-import</a><br>
<a href="https://wiki.openstack.org/wiki/Glance-tasks-export" target="_blank">
https://wiki.openstack.org/wiki/Glance-tasks-export</a><br>
<a href="https://wiki.openstack.org/wiki/Glance-tasks-clone" target="_blank">
https://wiki.openstack.org/wiki/Glance-tasks-clone</a><br>
<br>
Finally, here's a link to an experimental "product" page for this feature:<br>
<a href="https://wiki.openstack.org/wiki/Glance-tasks-api-product" target="_blank">
https://wiki.openstack.org/wiki/Glance-tasks-api-product</a><br>
<br>
cheers,<br>
brian<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</body>
</html>