Open Stack

Hi Kevin,

In an asynchronous environment that may have multiple clients sending commands to the same resource in a service, an "operation"-type resource is a fundamental prerequisite to creating client applications which report the status of ongoing operations. Without this resource, there is no way to tell a user whether an operation they attempted succeeded or failed.

Due to the importance of allowing users to see the results of individual operations on resources, I would treat the other features potentially provided by this type of resource, such as queuing or canceling operations, separately from the fundamental status reporting behavior.

Thank you,
Sam Harwell

-----Original Message-----
From: Kevin L. Mitchell [mailto:kevin.mitchell at rackspace.com] 
Sent: Wednesday, October 15, 2014 10:49 AM
To: openstack-dev
Subject: [openstack-dev] [api] API recommendation

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?
--
Kevin L. Mitchell <kevin.mitchell at rackspace.com> Rackspace


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev