Sorry for top-posting, but Salvatore and Dean, you might find my proposed "vNext" Compute API interesting, since it does what you are describing you'd like to see with regards to task-based APIs:

Specifically, the schemas and endpoints for tasks and subtasks:

When you call to POST /servers, you can create multiple servers:

And the _links JSON-HAL document returned by the POST /servers API call contains a "describedby" hyperlink that points to the JSONSchema document for a server object, and a "rel/server_tasks" hyperlink that points to a URL that may be used to determine the tasks and task states for any task involved in creating the server.


On 10/16/2014 05:57 AM, Salvatore Orlando wrote:
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 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)


On 16 October 2014 08:38, Christopher Yeoh <
<>> wrote:

On Thu, Oct 16, 2014 at 7:19 AM, Kevin L. Mitchell
< <>>

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


Something like ?

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

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


_______________________________________________ OpenStack-dev mailing

_______________________________________________ OpenStack-dev mailing

OpenStack-dev mailing list

Reply via email to