[openstack-dev] Problem with how python-neutronclient deals with Neutron exceptions
jpittier at octo.com
Thu Jul 4 16:24:47 UTC 2013
Nova-api makes extensive use of python-neutronclient. But the only
exception from neutronclient that nova-api catches is the
generic QuantumClientException (defined in
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
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 :
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev