<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2014-10-16 17:57 GMT+08:00 Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">In an analysis we recently did for managing lifecycle of neutron resources, it also emerged that task (or operation) API are a very useful resource.<div>Indeed several neutron resources introduced the (in)famous PENDING_XXX operational statuses to note the fact that an operation is in progress and its status is changing.</div><div><br></div><div>This could have been easily avoided if a facility for querying active tasks through the API was available.</div><div><br></div><div>From an API guideline viewpoint, I understand that <a href="https://review.openstack.org/#/c/86938/" target="_blank">https://review.openstack.org/#/c/86938/</a> proposes the introduction of a rather simple endpoint to query active tasks and filter them by resource uuid or state, for example.</div><div>While this is hardly questionable, I wonder if it might be worth "typifying" the task, ie: adding a resource_type attribute, and/or allowing to retrieve active tasks as a chile resource of an object, eg.: GET /servers/<server_id>/tasks?state=running or if just for running tasks GET /servers/<server_id>/active_tasks<br></div><div><br></div><div>The proposed approach for the multiple server create case also makes sense to me. Other than "bulk" operations there are indeed cases where a single API operation needs to perform multiple tasks. For instance, in Neutron, creating a port implies L2 wiring, setting up DHCP info, and securing it on the compute node by enforcing anti-spoof rules and security groups. This means there will be 3/4 active tasks. For this reason I wonder if it might be the case of differentiating between the concept of "operation" and "tasks" where the former is the activity explicitly initiated by the API consumer, and the latter are the activities which need to complete to fulfil it. This is where we might leverage the already proposed request_id attribute of the task data structure.</div></div></blockquote><div><br></div><div>This sounds like sub-task. The propose from Andrew include the sub-task concept, it just didn't implement in the first step.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Finally, a note on persistency. How long a completed task, successfully or not should be stored for? Do we want to store them until the resource they operated on is deleted?</div><div>I don't think it's a great idea to store them indefinitely in the DB. Tying their lifespan to resources is probably a decent idea, but time-based cleanup policies might also be considered (e.g.: destroy a task record 24 hours after its completion)</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></blockquote><div><br></div><div>This is good point! Task can be removed after finished except failed. And maybe can implement plugin mechanism to add different persistency backend?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="HOEnZb"><font color="#888888"><div></div><div>Salvatore</div><div><br></div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 16 October 2014 08:38, Christopher Yeoh <span dir="ltr"><<a href="mailto:cbkyeoh@gmail.com" target="_blank">cbkyeoh@gmail.com</a>></span> 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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>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><div>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></span></blockquote><div><br></div></div></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" target="_blank">https://review.openstack.org/127127</a><br></div><div> </div><div>Regards,</div><div><br></div><div>Chris</div></div></div></div>
<br></div></div><span class="">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></span></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>