Basically #2 makes sense to me. > 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).
What granularity are you thinking? I am not sure what information is passed as "type" and "detail". Could you give an example you think? Exceptions in neutron-server side are classified into categories and a status code of response is determined based on these categories. There is a case where multiple categories are mapped into a single status code. If the granularity of the client exceptions is same as these categories, it seems easy to map categories into client-side exceptions (by using "type"). If more detail granularity is needed, the situation becomes more complicated. If we map server-side exception into client-side exception one to one, whenever server-side exceptions changes/increases neutron client needs to catch up with it In addition some exceptions are sometimes defined in extensions. This makes more difficult to one-to-one mapping. Any thought? Thanks, Akihiro 2013/7/5 Jordan Pittier <[email protected]> > 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 > > -- Akihiro MOTOKI <[email protected]>
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
