QuantumOpStatus
Operational status for Quantum resources
At the Essex design summit it was agreed to augment Quantum resources with the concept of "Operational Status". This wiki page discusses the syntax and the semantics for this concept.
The need for the "Operational Status" concept
The Operational status reflects the current state of the resources managed by the plugin.
For instance, if the plugin asynchronously perform all the actions required for creating or updating a network or a port, there will be a lag of time in which the resource will not be operative. Examples of situations in which a resource might not be operative include faults, insufficient capabilities in the physical or virtual switching layer, or simply, in the case of ports, the fact that there's no attachment plugged into it (i.e.: link down).
By introducing this concept Quantum clients will become aware of the actual state of the resources managed by Quantum. In particular, this concept will help Quantum client deal with:
- Asynchronous behaviour of Quantum Plugins
- Failures in Quantum Networks
The operational status will be added to network and port resources.; there's no need to add an operational status to attachments.
Operational Status semantics
The operational status simply describes the current availability state of a particular Quantum resource. It is quite different from the concept of administrative status which has already been introduced for ports in v1.0 of the Quantum API.
While the administrative status is controller by the client which can programmatically activate or deactivate a port, the operational status is a read-only attribute that the client need to consume in order to understand whether a specific resource is actually working or not.
It is important to keep in mind that the operational status is an attribute of the API layer object, which is something different from the objects that actually provide the networking resources in the virtual/physical switching layer, as depicted in the picture below; the API layer object exists regardless of the status of the resources in the virtual/physical switching
Therefore, when a resource is not operational, the Quantum API will still accept operations on that resources and dispatch them to the plugin. Should that resource be operationally unavaiable, the behaviour of the operation is then plugin specific. Some plugins can immediately return with an error code, whereas other plugin might decide to accept the operation, queue it, and execute it when the resource will become available.
Nevertheless, by exposing a consistent operational state for a resource, the Quantum API will guarantee a consistent behaviour for client regardless of the particular plugin.
Changes into Quantum API
The set of operations exposed by the Quantum API will not change for taking into account the operational status. The only difference will be an extra attribute returned in responses.
The operational status attribute will be an enumerative type, which can assume the following values:
- UP: the resource is operationally available;
- PROVISIONING: the plugin is creating/updating the components for the resource;
- DOWN: the resource is not operational (i.e.: port without an attachment);
- FAILED: one or more components providing the resource in the plugin are in a failure state.
This implies that responses for GET operation on networks and ports will change as follows.
NOTE: The operational status attribute will be visible only to client explicitly using Quantum API v1.1
When a resource is operationally unavailable, it is perfectly reasonable for clients to query the API layer for an explanation, as the enum value for the operational status might not be enough. In this case, a descriptive, plugin-specific, text attribute for the current status of the resource will be returned by the detail action, which is already available for both networks and ports.
