<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 16, 2014 at 4:57 AM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>That review/blueprint contains one thing that I want to address in more detail below along with Sal's comment on persistence...</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>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</div></div></blockquote><div><br></div><div>I'd prefer the filter approach, but more importantly, it should be the _same_ structure as listing resources themselves.</div><div><br></div><div>To note: here is another API design detail, specifying resource types in the URL path:</div><div><br></div><div>/server/<server>/foo</div><div><br></div><div>vs</div><div><br></div><div>/<server>/foo</div><div><br></div><div>or what we have today, for example, in compute:</div><div><br></div><div>/<tenant>/foo</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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>I like the ability to track the fan-out, especially if I can get the state of the entire set of tasks in a single round-trip.  This also makes it easier to handle backout of failed requests without having to maintain a lot of client-side state, or make a lot of round-trips.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></div></blockquote><div><br></div><div>I can envision an operator/user wanting to be able to pull a log of an operation/task for not only cloud debugging (x failed to build, when/why?) but also app-level debugging (concrete use case not ready at deadline).  This would require a minimum of life-of-resource + some-amount-of-time.  The time might also be variable, failed operations might actually need to stick around longer.</div><div><br></div><div>Even as an operator with access to backend logging, pulling these state transitions out should not be hard, and should be available to the resource owner (project).</div></div><div class="gmail_extra"><br></div>dt<br clear="all"><div><br></div>-- <br><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br>
</div></div>