Open Stack

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 <john at bresnahan.me
> <mailto:john at bresnahan.me>> 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 (george.reese at imaginary.com
>>> <mailto:george.reese at imaginary.com>)
>>> t: @GeorgeReese               m: +1(207)956-0217
>>> <tel:%2B1%28207%29956-0217>               Skype: nspollution
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> 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
>
> --
> George Reese (george.reese at imaginary.com
> <mailto:george.reese at imaginary.com>)
> t: @GeorgeReese               m: +1(207)956-0217
> <tel:%2B1%28207%29956-0217>               Skype: nspollution
>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>