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.
Kevin L. Mitchell <kevin.mitch...@rackspace.com>

OpenStack-dev mailing list

Reply via email to