I think approach #2 makes sense. I can take a stab at it, but I am not guaranteeing any delivery dates.
Do you have a specific api/exception that you would like to test to see if the concept works for nova-api? The one bug you mention singles out associating a floating IP to a port. That might be a good one to try. Anything that is easy to set up and test in devstack. We may have to be careful not to leak privileged information up the chain. -- Henry On Thu, Jul 04, at 12:24 am, Jordan Pittier <[email protected]> wrote: > Hi guys, > > Nova-api makes extensive use of python-neutronclient. But the only exception > from neutronclient that nova-api catches is the > generic QuantumClientException (defined in > quantumclient/common/exceptions.py). > > neutronclient has some more specific exceptions > like PortInUseClient, NetworkNotFoundClient. But they are never raised > because I believe there is a bug either in neutron server or in > neutronclient, related to exceptions. > > In neutronclient, all exceptions are handled in > neutronclient/v2_0/client.py::exception_handler_v20(). The code is supposed > to catch a Neutron(Server)Exception and raise the corresponding specific > NeutronClientException. In order to do that, NeutronClient expects the > deserialized Neutron(Server)Exception to be a dictionnary which has the keys > "type","message" and "detail". But, these keys are never found in any > Neutron(Server)Exceptions so, instead the generic NeutronClientException is > raised. > > If you look at how Neutron(Server) exceptions are defined > (quantum/quantum/common/exceptions.py), indeed there's no mention of 'type' > or 'detail' (though 'message' is defined). So its "logic" that neutronclient > always raises the generic NeutronClientException. > > Also see this bug reports : > https://bugs.launchpad.net/python-neutronclient/+bug/1178734 > https://bugs.launchpad.net/python-neutronclient/+bug/1187698 > > > What should we do about this ? : > 1) Pretty much nothing. Nova-api still catches only the generic > NeutronClientException, and based the further processing of the exception on > the correct status_code reported by neutronclient. In that case, we should > clean the code of neutronclient::exception_handler_v20() because it has a > lot of dead code. > 2) Enrich/enhance the NeutronServer exceptions with a type and detail > properties. This way, when a NeutronServer exception is serialized and sent > to python-neutronclient, the specific NeutronClient exception can be raised > (and then sent to nova-api). > 3) You tell me :) ! > > Thanks a lot > Jordan > > > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
