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 : [email protected] Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
