<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 16, 2014 at 7:19 AM, Kevin L. Mitchell <span dir="ltr"><<a href="mailto:kevin.mitchell@rackspace.com" target="_blank">kevin.mitchell@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Wed, 2014-10-15 at 12:39 -0400, Andrew Laski wrote:<br>
> On 10/15/2014 11:49 AM, Kevin L. Mitchell wrote:<br>
> > Now that we have an API working group forming, I'd like to kick off some<br>
> > discussion over one point I'd really like to see our APIs using (and<br>
> > I'll probably drop it in to the repo once that gets fully set up): the<br>
> > difference between synchronous and asynchronous operations.  Using nova<br>
> > as an example—right now, if you kick off a long-running operation, such<br>
> > as a server create or a reboot, you watch the resource itself to<br>
> > determine the status of the operation.  What I'd like to propose is that<br>
> > future APIs use a separate "operation" resource to track status<br>
> > information on the particular operation.  For instance, if we were to<br>
> > rebuild the nova API with this idea in mind, booting a new server would<br>
> > give you a server handle and an operation handle; querying the server<br>
> > resource would give you summary information about the state of the<br>
> > server (running, not running) and pending operations, while querying the<br>
> > operation would give you detailed information about the status of the<br>
> > operation.  As another example, issuing a reboot would give you the<br>
> > operation handle; you'd see the operation in a queue on the server<br>
> > resource, but the actual state of the operation itself would be listed<br>
> > on that operation.  As a side effect, this would allow us (not require,<br>
> > though) to queue up operations on a resource, and allow us to cancel an<br>
> > operation that has not yet been started.<br>
> ><br>
> > Thoughts?<br>
><br>
> Something like <a href="https://review.openstack.org/#/c/86938/" target="_blank">https://review.openstack.org/#/c/86938/</a> ?<br>
><br>
> I know that Jay has proposed a similar thing before as well.  I would<br>
> love to get some feedback from others on this as it's something I'm<br>
> going to propose for Nova in Kilo.<br>
<br>
</div></div>Yep, something very much like that :)  But the idea behind my proposal<br>
is to make that a codified API guideline, rather than just an addition<br>
to Nova.<br>
<span class="im"></span></blockquote><div><br></div><div>Perhaps the best way to make this move faster is for developers not from Nova</div><div>who are interested to help develop the tasks api spec Andrew pointed to. Its been</div><div> on the Nova to-do list for a few cycles now and had quite a bit of discussion both</div><div>at mid cycles and summit meetings. </div><div><br></div><div>Once we have a nova spec approved we can extract the project common parts</div><div>out into the API guidelines.</div><div><br></div><div>I think we really want microversions up so we can make backwards incompatible API</div><div>changes when we implement the API side of tasks, but that is something members</div><div>of the API WG are hopefully interested in too.</div><div><br></div><div><a href="https://review.openstack.org/127127">https://review.openstack.org/127127</a><br></div><div> </div><div>Regards,</div><div><br></div><div>Chris</div></div></div></div>