If we are planning to lock down our API v1.0 before Diablo-4, we can just target the API blueprint to D-4.
Salvatore From: Dan Wendlandt [mailto:[email protected]] Sent: 02 August 2011 22:15 To: Salvatore Orlando Cc: [email protected] Subject: Re: [Netstack] Aligning API implementation with specification 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]<mailto:[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]<mailto:[email protected]> Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com<http://www.nicira.com> | www.openvswitch.org<http://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
