Hi, I've registered a blueprint regarding the Quantum API framework: https://blueprints.launchpad.net/quantum/+spec/api-framework-essex
Our framework currently diverges from Nova's Openstack API framework. I think that there are several benefits in realigning them: 1. We get a much cleaner solution to the issue of create methods not returning 202 (which is still an outstanding bug, as we had to revert the fix before the release: https://bugs.launchpad.net/quantum/+bug/834013 2. We get a deserializer which is much better than the current _parse_request_params method in QuantumController. This serializer will allow us to pass a dictionary with the whole deserialized body (in a dict) to the plugin; IMHO this would solve the problem of passing arbitrary extended attributes from the API layer to the plugin. 3. The Quantum API controllers will be 'ready' to transition to Openstack-commons, as soon as a common WSGI framework will be available In this blueprint we should also 'divide' the API v1.0 from the APIv1.1 in terms of: * WSGI pipeline (/etc/quantum.conf) * API controllers (the 1.1 controllers will return the 'operational status') * API routers (well there's no difference in terms of Operations, but we need to divide them since the controllers are slightly different) Your feedback is more than welcome! 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
