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 [pauldbou...@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
mailto:brian.rosma...@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-expo
