Open Stack

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.
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.

This could have been easily avoided if a facility for querying active tasks
through the API was available.

>From an API guideline viewpoint, I understand that
https://review.openstack.org/#/c/86938/ proposes the introduction of a
rather simple endpoint to query active tasks and filter them by resource
uuid or state, for example.
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

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.

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?
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)

Salvatore


On 16 October 2014 08:38, Christopher Yeoh <cbkyeoh at gmail.com> wrote:

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