Great write-up Salvatore, comments inline. dan
On Tue, Aug 2, 2011 at 4:34 PM, Salvatore Orlando < salvatore.orla...@eu.citrix.com> wrote: > 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. > To further emphasize the point, even in the rather simple OVS plugin the operation of "attaching" an interface to a port is asynchronous. The plugin creates a new port row in the database, and the agent on the hypervisor monitors the DB for changes and asynchronously puts the port on that VLAN. I suspect that pretty much all plugins will have some amount of asynchronous behavior. > **** > > ** ** > > *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. > I am in favor of a status field. I want to make sure we're thinking about more than just provisioning though. Provisioning is one case in which the "logical" connectivity described in the API has not yet been mapped to the real world, but there can be other cases as well. For example, if your solution has an agent on the hypervisor and that agent no longer is running, how do you indicate the fact that this port is no longer "controlled" by quantum. I've spent a lot of time working with systems like this, and in my experience these types of situations are actually pretty common. A similar case is how do we indicate if someone has specified an interface-id, but the system does not see any ports with that interface id? An abstraction that I like for this is that of a "logical link status". If this status is "up", the logical connectivity described via the API is the connectivity the VM interface sees. If it is down, there is a mismatch. The plugin could then return a "link_status_string" indicating why the status is down (e.g., "interface-id not found"). > **** > > ** ** > > The API will reject operations on resources which are not available, unless > they are GET operations. > As I mentioned in the IRC chat, I think this one requires some more discussion. Would I be able to create a port, attach an interface to it, and configure a QoS policy right away, even if provisioning took a while? This seems potentially cumbersome for the client. If the client wanted to wait until the port was in a particular state before applying additional configuration, it would seem like the client code to do that would be fairly simple, but I suspect other clients would prefer just to fire off the configuration without waiting. > **** > > ** ** > > 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 > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | www.openvswitch.org Sr. Product Manager cell: 650-906-2650 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
