Sorry for top-posting, but in summary, I entirely agree with George
here. His logic is virtually identical to the concerns I raised with the
initial proposal for Glance Tasks here:
http://lists.openstack.org/pipermail/openstack-dev/2013-May/009400.html
and
http://lists.openstack.org/pipermail/openstack-dev/2013-May/009527.html
Best,
-jay
On 11/13/2013 05:36 PM, George Reese wrote:
Let’s preface this with Glance being the part of OpenStack I am least
familiar with. Keep in mind my commentary is related to the idea that
the asynchronous tasks as designed are being considered beyond Glance.
The problems of image upload/import/cloning/export are unlike other
OpenStack operations for the most part in that they involve binary data
as the core piece of the payload.
Having said that, I’d prefer a polymorphic POST to the tasks API as
designed. But I’m much more concerned with the application of the tasks
API as designed to wider problems.
Basically, I’d stick with POST /images.
The content type should indicate what the server should expect.
Basically, the content can be:
* An actual image to upload
* Content describing a target for an import
* Content describing a target for a clone operation
Implementation needs dictate whether any given operation is synchronous
or asynchronous. Practically speaking, upload would be synchronous with
the other two being asynchronous. This would NOT impact an existing
/images POST as it will not change (unless we suddenly made it
asynchronous).
The response would be CREATED (synchronous) or ACCEPTED (asynchronous).
If ACCEPTED, the body would contain JSON/XML describing the asynchronous
task.
I’m not sure if export is supposed to export to a target object store or
export to another OpenStack environment. But it would be an async
operation either way and should work as described above. Whether the
endpoint for the image to be exported is the target or just /images is
something worthy of discussion based on what the actual function of the
export is.
-George
On Nov 12, 2013, at 5:45 PM, John Bresnahan <[email protected]
<mailto:[email protected]>> wrote:
George,
Thanks for the comments, they make a lot of sense. There is a Glance
team meeting on Thursday where we would like to push a bit further on
this. Would you mind sending in a few more details? Perhaps a sample
of what your ideal layout would be? As an example, how would you
prefer actions are handled that do not effect a currently existing
resource but ultimately create a new resource (for example the import
action).
Thanks!
John
On 11/11/13, 8:05 PM, George Reese wrote:
I was asked at the OpenStack Summit to look at the Glance Tasks,
particularly as a general pattern for other asynchronous operations.
If I understand Glance Tasks appropriately, different asynchronous
operations get replaced by a single general purpose API call?
In general, a unified API for task tracking across all kinds of
asynchronous operations is a good thing. However, assuming this
understanding is correct, I have two comments:
#1 A consumer of an API should not need to know a priori whether a
given operation is “asynchronous”. The asynchronous nature of the
operation should be determined through a response. Specifically, if
the client gets a 202 response, then it should recognize that the
action is asynchronous and expect a task in the response. If it gets
something else, then the action is synchronous. This approach has the
virtual of being proper HTTP and allowing the needs of the
implementation to dictate the synchronous/asynchronous nature of the
API call and not a fixed contract.
#2 I really don’t like the idea of a single endpoint (/v2/tasks) for
executing all tasks for a particular OpenStack component. Changes
should be made through the resource being impacted.
-George
--
George Reese ([email protected]
<mailto:[email protected]>)
t: @GeorgeReese m: +1(207)956-0217
<tel:%2B1%28207%29956-0217> Skype: nspollution
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
George Reese ([email protected]
<mailto:[email protected]>)
t: @GeorgeReese m: +1(207)956-0217
<tel:%2B1%28207%29956-0217> Skype: nspollution
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
