When considering user interfaces, the choice of task and/or status reporting methods can have a big impact on the ability to communicate with the user. In particular, status properties (e.g. in the manner of compute V2 servers) prevent user interfaces from associating the result of an operation with a description of an executed action. Even though a REST API is a theoretically a set of synchronous operations to transform basic data resources, in reality users are initiating actions against their account that do not reach their final state immediately.
In designing an API, the ability to provide users with relevant information about decisions and actions they take is of utmost importance. Since a separate task representation (e.g. glance) does support providing users with information about the ongoing and final result of specific actions they perform, where a status field does not, we will eventually need to use a task representation in order to properly support our users. Also, the specific detail of whether a resource supports more than one asynchronous operation concurrently (or supports queueing of task operations) is not applicable to this decision. Cloud resources are inherently a distributed system, and individual clients are not able to determine which status is associated with particular actions. For example, consider the following: 1. Client A request operation X be performed 2. Operation X completes successfully 3. Client B requests operation Y be performed 4. Operation Y results in the resource entering an error state 5. Client A checks the status of the resource In this scenario, Client A is unable to report to the user which operation resulted in the resource entering its current error state. If it attempts to report the information according to the information available to it, the user would be under the impression that Operation X caused the resource to enter the error state, with clearly negative impacts on their ability to understand the problem(s) encountered and steps they should take to resolve the situation during their use of the API. Please keep in mind that this message is not related to particular implementation, storage mechanism, or the manner in which clients communicate with the server. I am simply pointing out that the needs of end users can only be properly met by ensuring that particular information is available through the API their applications are using. This is (or should be) the primary driver for design decisions made during the creation of each API. Thank you, Sam Harwell -----Original Message----- From: Robert Collins [mailto:robe...@robertcollins.net] Sent: Tuesday, June 03, 2014 4:36 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Introducing task oriented workflows On 23 May 2014 10:34, Salvatore Orlando <sorla...@nicira.com> wrote: > As most of you probably know already, this is one of the topics discussed > during the Juno summit [1]. > I would like to kick off the discussion in order to move towards a concrete > design. > > Preamble: Considering the meat that's already on the plate for Juno, I'm not > advocating that whatever comes out of this discussion should be put on the > Juno roadmap. However, preparation (or yak shaving) activities that should > be identified as pre-requisite might happen during the Juno time frame > assuming that they won't interfere with other critical or high priority > activities. > This is also a very long post; the TL;DR summary is that I would like to > explore task-oriented communication with the backend and how it should be > reflected in the API - gauging how the community feels about this, and > collecting feedback regarding design, constructs, and related > tools/techniques/technologies. Hi, thanks for writing this up. A few thoughts: - if there can be only one task on a resource at a time, you're essentially forcing all other clients to poll for task completion before coming back to do *their* change. Its kindof a pathological edge case of no in-flight-conflicts :). - Please please please don't embed polling into the design - use webhooks or something similar so that each client (be that Nova, Ironic, Horizon or what-have-you - can get a push response when the thing they want to happen has happened). - I'd think very very carefully about whether you're actually modelling /tasks/ or whether tasks are the implementation and really the core issue is modelling the desired vs obtained resource state - Ironic has a debate going on right now about very much the same problem - the latency involved in some API tasks, and whether the API should return when complete, or when the work his guaranteed to start, or even immediately and maybe the work isn't guaranteed to start. My feeling is that we need to balance ease and correctness of implementation, ease (and efficiency/correctness) of use, and robustness - an entirely non-blocking API might end up being the polling nightmare of nightmares if not done carefully, for instance. -Rob _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
