Open Stack

Hi Paul,

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.

Briefly,

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.

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.

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.

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.

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.

Anyway, this has gotten long enough.  Thanks for kicking off the new discussion!

cheers,
brian

________________________________
From: Paul Bourke [pauldbourke at gmail.com]
Sent: Thursday, August 01, 2013 11:21 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Glance] images tasks API -- final call for comments

Hi Brian,

I had a read over the summary wiki page and the individual docs.

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: http://lists.openstack.org/pipermail/openstack-dev/2013-May/009527.html

Was there any follow up to that mail? (sorry if I missed it!)

Thanks,
-Paul


On 30 July 2013 19:36, Brian Rosmaita <brian.rosmaita at rackspace.com<mailto:brian.rosmaita at rackspace.com>> wrote:
After lots of discussion, here are the image import/export/cloning blueprints unified as a tasks API.  Please reply with comments!

Take a look at this doc first:
    https://wiki.openstack.org/wiki/Glance-tasks-api
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:
    https://wiki.openstack.org/wiki/Glance-tasks-import
    https://wiki.openstack.org/wiki/Glance-tasks-export
    https://wiki.openstack.org/wiki/Glance-tasks-clone

Finally, here's a link to an experimental "product" page for this feature:
    https://wiki.openstack.org/wiki/Glance-tasks-api-product

cheers,
brian

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130802/1ae20035/attachment.html>