<div dir="ltr">Responses to both Jay and George inline.<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 5:08 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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:<br>
<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-May/009400.html" target="_blank">http://lists.openstack.org/<u></u>pipermail/openstack-dev/2013-<u></u>May/009400.html</a><br>
and<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-May/009527.html" target="_blank">http://lists.openstack.org/<u></u>pipermail/openstack-dev/2013-<u></u>May/009527.html</a></blockquote><div><br></div><div>
In my understanding, your viewpoints are subtly different.</div><div><br></div><div>George seems to agree with representing ongoing asynchronous tasks through a separate 'tasks' resource. I believe where he differs with the current design is how those tasks are created. He seems to prefer creating tasks with POST requests to the affected resources. To distinguish between uploading an image and importing an image, he suggests we require a different content type in the request.</div>
<div><br></div><div>However, your main point in the links above seemed to be to reuse POST /v2/images, but to capture the asynchronous nature of image verification and conversion by adding more nodes to the image state machine.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Best,<br>
-jay<div><div class="h5"><br>
<br>
On 11/13/2013 05:36 PM, George Reese wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Let’s preface this with Glance being the part of OpenStack I am least<br>
familiar with. Keep in mind my commentary is related to the idea that<br>
the asynchronous tasks as designed are being considered beyond Glance.<br>
The problems of image upload/import/cloning/export are unlike other<br>
OpenStack operations for the most part in that they involve binary data<br>
as the core piece of the payload.<br>
<br>
Having said that, I’d prefer a polymorphic POST to the tasks API as<br>
designed.</div></div></blockquote></blockquote><div><br></div><div>Thanks. I think we'll move forward with this design for now in Glance. But your alternative below is compelling and we'll definitely consider as we add future tasks. I also want to say that we could probably completely adopt your proposal in the future as long as we also support backwards compatibility with the current design, but I can't predict at this point the practical concerns that will emerge.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div class="h5">But I’m much more concerned with the application of the tasks<br>
API as designed to wider problems.<br></div></div></blockquote></blockquote><div><br></div><div>I think this concern is very reasonable. Other projects should evaluate your proposal carefully.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
Basically, I’d stick with POST /images.<br>
<br>
The content type should indicate what the server should expect.<br>
Basically, the content can be:<br>
<br>
* An actual image to upload<br>
* Content describing a target for an import<br>
* Content describing a target for a clone operation<br>
<br>
Implementation needs dictate whether any given operation is synchronous<br>
or asynchronous. Practically speaking, upload would be synchronous with<br>
the other two being asynchronous. This would NOT impact an existing<br>
/images POST as it will not change (unless we suddenly made it<br>
asynchronous).<br>
<br>
The response would be CREATED (synchronous) or ACCEPTED (asynchronous).<br>
If ACCEPTED, the body would contain JSON/XML describing the asynchronous<br>
task.<br>
<br>
I’m not sure if export is supposed to export to a target object store or<br>
export to another OpenStack environment. But it would be an async<br>
operation either way and should work as described above. Whether the<br>
endpoint for the image to be exported is the target or just /images is<br>
something worthy of discussion based on what the actual function of the<br>
export is.<br>
<br>
-George<br>
<br>
On Nov 12, 2013, at 5:45 PM, John Bresnahan <<a href="mailto:john@bresnahan.me" target="_blank">john@bresnahan.me</a><br></div></div>
<mailto:<a href="mailto:john@bresnahan.me" target="_blank">john@bresnahan.me</a>>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
George,<br>
<br>
Thanks for the comments, they make a lot of sense. There is a Glance<br>
team meeting on Thursday where we would like to push a bit further on<br>
this. Would you mind sending in a few more details? Perhaps a sample<br>
of what your ideal layout would be? As an example, how would you<br>
prefer actions are handled that do not effect a currently existing<br>
resource but ultimately create a new resource (for example the import<br>
action).<br>
<br>
Thanks!<br>
<br>
John<br>
<br>
<br>
On 11/11/13, 8:05 PM, George Reese wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
I was asked at the OpenStack Summit to look at the Glance Tasks,<br>
particularly as a general pattern for other asynchronous operations.<br>
<br>
If I understand Glance Tasks appropriately, different asynchronous<br>
operations get replaced by a single general purpose API call?<br>
<br>
In general, a unified API for task tracking across all kinds of<br>
asynchronous operations is a good thing. However, assuming this<br>
understanding is correct, I have two comments:<br>
<br>
#1 A consumer of an API should not need to know a priori whether a<br>
given operation is “asynchronous”. The asynchronous nature of the<br>
operation should be determined through a response. Specifically, if<br>
the client gets a 202 response, then it should recognize that the<br>
action is asynchronous and expect a task in the response. If it gets<br>
something else, then the action is synchronous. This approach has the<br>
virtual of being proper HTTP and allowing the needs of the<br>
implementation to dictate the synchronous/asynchronous nature of the<br>
API call and not a fixed contract.<br>
<br>
#2 I really don’t like the idea of a single endpoint (/v2/tasks) for<br>
executing all tasks for a particular OpenStack component. Changes<br>
should be made through the resource being impacted.<br>
<br>
-George<br>
<br>
--<br>
George Reese (<a href="mailto:george.reese@imaginary.com" target="_blank">george.reese@imaginary.com</a><br></div></div>
<mailto:<a href="mailto:george.reese@imaginary.com" target="_blank">george.reese@<u></u>imaginary.com</a>>)<br>
t: @GeorgeReese m: <a href="tel:%2B1%28207%29956-0217" value="+12079560217" target="_blank">+1(207)956-0217</a><br>
<tel:%2B1%28207%29956-0217> Skype: nspollution<div class="im"><br>
<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></blockquote><div class="im">
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br></div>
<mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br><span class="HOEnZb"><font color="#888888">
--<br>
George Reese (<a href="mailto:george.reese@imaginary.com" target="_blank">george.reese@imaginary.com</a><br>
<mailto:<a href="mailto:george.reese@imaginary.com" target="_blank">george.reese@<u></u>imaginary.com</a>>)<br>
t: @GeorgeReese m: <a href="tel:%2B1%28207%29956-0217" value="+12079560217" target="_blank">+1(207)956-0217</a><br>
<tel:%2B1%28207%29956-0217> Skype: nspollution</font></span><div class="im"><br>
<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a></div></div></blockquote><div><br></div></div>
</div></div>