Open Stack

2014-10-16 17:57 GMT+08:00 Salvatore Orlando <sorlando at nicira.com>:

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

This sounds like sub-task. The propose from Andrew include the sub-task
concept, it just didn't implement in the first step.


>
> 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)
>
>
This is good point! Task can be removed after finished except failed. And
maybe can implement plugin mechanism to add different persistency backend?



> 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
>>
>>
>
> _______________________________________________
> 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/9fd1a784/attachment.html>