Great work Salvatore. I'd really like to have v1.0 of the API in Diablo-4, so let's make sure we have a bug or blueprint targeted for that drop.
Some thoughts inline below. Dan On Tue, Aug 2, 2011 at 9:39 AM, Salvatore Orlando < [email protected]> wrote: > Hi, **** > > ** ** > > In order to finalize a “v1.0” for the Quantum API we are currently > reviewing its specification and implementation. **** > > ** ** > > The reviewed API specification is much closer to the Openstack API. > However, there are a few “corner cases”: **** > > **- **Get Attached Resource operation: if no attachment is > plugged into a port should we raise an error? > I would think that calling this might be done by a client to check whether the interface has something attached or not, in which case returning a NULL value would seem appropriate (this is easy to do in JSON, not sure about XML). > **** > > **- **Plugging an attachment in port whose state is ‘DOWN’. I > think this should be disallowed, and an exception raised. What’s your > opinion? > I think of the 'state' field as being similar to the 'admin status' of a physical switch, in which case it would be valid to plug an interface into a port that is admin down. Likewise, it is valid to put a port in admin down even once it has something plugged into it (this can be simpler than detaching and reattaching). > **** > > ** ** > > The code currently diverges from the API. Realignment is being done in the > branch lp:~salvatore-orlando/quantum/quantum-api-aligment, linked to bug > #813433.**** > > Also two other branches contain code which will contribute to realign the > API impl with its spec. One removes the “PortCount” attribute, whereas the > other introduces the NetworkNameExists fault, which can be raised upon > network create/update operations.**** > > ** ** > > The next step will involve fixing accordingly unit tests and the client > library (which is going to hit trunk very soon). All of this will be done > within the api-alignment branch.**** > > ** ** > > The final step is to take a decision wrt synchronous vs asynchronous > behaviour of the API. **** > > I sent an email a couple of days ago on this topic. I thought a little bit > more about it, and I think it is reasonable that the actual behaviour > depends on the particular plugin implementation. It does not make a lot of > sense to force something which is inherently synchronous to be asynchronous. > **** > > However, a concept of “provisioning status” is probably need for Quantum > resources, and this status should be available through the API. **** > > Enumeration for resource statuses could be similar to the power_mapping > enumeration in Openstack API. **** > > In this way a synchronous plugin could return resource whose state is > typically “ACTIVE”, whereas an asynchronous plugin would return resources > whose state is usually “BUILD”. **** > > API users will be aware of this, as the status of an operation will be > clearly documented in the API specification. On the other hand, the API will > refuse to execute operations on resource whose provisioning state is not > “ACTIVE”. > I like the idea of an enumerated status here. I want to think more about whether the API should reject calls during a "build" phase. I was more thinking that the API user could make whatever requests they want at any point, but a status might indicate that the system has not yet been able to actually provision the corresponding network behavior. > **** > > ** ** > > I would be more than happy to discuss these item during today’s meeting. My > aim is to lock down the specification as soon as possible (end of the > week?), and then merge the alignment branch shortly after. > Great. Given how long our meetings have been running, longer debates should probably live on the mailing list, but I already have a spot on the agenda to discuss the API spec. > **** > > ** ** > > Regards, **** > > Salvatore**** > > ** ** > > -- > Mailing list: https://launchpad.net/~netstack > Post to : [email protected] > 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 : [email protected] Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
