<p dir="ltr"><br>
On Oct 16, 2014 8:24 AM, "Dean Troyer" <<a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Thu, Oct 16, 2014 at 4:57 AM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:<br>
>><br>
>> From an API guideline viewpoint, I understand that <a href="https://review.openstack.org/#/c/86938/">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.<br>
><br>
><br>
> That review/blueprint contains one thing that I want to address in more detail below along with Sal's comment on persistence...<br>
>  <br>
>><br>
>> 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>
><br>
><br>
> I'd prefer the filter approach, but more importantly, it should be the _same_ structure as listing resources themselves.<br>
><br>
> To note: here is another API design detail, specifying resource types in the URL path:<br>
><br>
> /server/<server>/foo<br>
><br>
> vs<br>
><br>
> /<server>/foo<br>
><br>
> or what we have today, for example, in compute:<br>
><br>
> /<tenant>/foo<br>
><br>
>> 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.<br>
><br>
><br>
> 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.<br>
></p>
<p dir="ltr">Based on previous experience, I highly recommend maintaining separation between tracking work at an API call level aggregate and other "subtasks." In non-provisioning scenarios, tasks may fire independent of API operations, so there wouldn't be an API handle to query on. It is great to manage per-API call level tasks in the framework. The "other work" type tasks are *much* more complicated beasts, deserving of their own design.<br></p>
<p dir="ltr">>> 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?<br>
>> 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)<br>
><br>
><br>
> 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.<br>
><br>
> 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).<br>
><br>
> dt<br>
><br>
> -- <br>
><br>
> Dean Troyer<br>
> <a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br>
><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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
</p>