Thanks Salvatore for outlining the efforts around aligning the API.
As for the issue of synchronous versus asynchronous. I agree that leaving it to the plugin to implement the behavior might be more flexible and also alleviate the burden on the API framework implementation. Having said that, each plugin that needs to implement the asynchronous behavior will have to implement the asynchronous mechanism, potentially leading to duplication of efforts across plugins (and also bugs). I am sure you must have thought of this, but I am just trying to bring out another data point to the table. As opposed to that, if the implementation is in the API framework, then we would always ensure asynchronous behavior. I am also trying to understand the scheme you have proposed below. When you talk about the "provisioning status", and that "this status should be available through the API", do you envision a separate API to obtain the status? Thanks, ~Sumit. From: netstack-bounces+snaiksat=cisco....@lists.launchpad.net [mailto:netstack-bounces+snaiksat=cisco....@lists.launchpad.net] On Behalf Of Salvatore Orlando Sent: Tuesday, August 02, 2011 9:40 AM To: netstack@lists.launchpad.net Subject: [Netstack] Aligning API implementation with specification 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? - Plugging an attachment in port whose state is 'DOWN'. I think this should be disallowed, and an exception raised. What's your opinion? 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 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. 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
