Open Stack

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 <jpittier at octo.com> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>