Following the discussion on synchronous vs asynchronous behaviour in the last Netstack meeting, we agreed to send around a proposal for introducing the concept of "Resource Status".
Goal: * Ensure consistent behaviour of the API w.r.t. users, meaning that the API should always behave in the same way regardless of the plugin used. Assumptions: * Plugins can implement any kind of behaviour: synchronous, or asynchronous. It is also possible to have plugins for which some operations are synchronous and other asynchronous; * Both the API and the plugin interface should be kept as simple as possible; we do not want unnecessary complexity; * API users need a mechanism to know whether an operation is completed or not. * A resource can "exist" but not be available yet, as the plugin might asynchronously perform all the operations required to provide it. Example (synchronous plugin) "Create network" on the OVS plugin adds a vlan binding into its own database and then return id and name of the newly created network Example (asynchronous plugin) Just guessing here... A plugin for 802.1qbh will probably have a more complex provisioning process, as it will involve configuring virtual switches, IV modules, and physical switches. The "Create network" operation will create an entry into the plugin db, start the provisioning process, and immediately return. The network will not yet be available. Proposal: The proposal simply consists of adding an extra "status" attribute to all the resource managed by the Quantum API, namely: network, port, and attachment. The status attribute will be of an enumeration type describing the current state of the resource, similarly to the homonymous attribute for the "Server" resource in the Openstack API. The actual values for the enumeration could be different for each resource. Possible Status enumeration values: NETWORK: "PROVISIONING","AVAILABLE","ERROR". PORT: "PROVISIONING","DOWN", "ACTIVE","ERROR". ATTACHMENT: "PROVISIONING", "AVAILABLE", "ERROR" Note: the "Port" resource already has a "state" attribute, which describes the administrative state of the port. The proposed enumeration merges this attribute into the "status" attribute. Adding the "status" attribute will enable users to be aware of the current provisioning state of the resource. Client application can then query the resource (e.g.: by polling it with GET requests), and check for its status. When the resource is available, they can perform operations on it. A synchronous plugin should directly mark the resource as available when it returns. The API will reject operations on resources which are not available, unless they are GET operations. Regards, Salvatore
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
