Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141016/10fbd4e0/attachment.html>