[openstack-dev] [neutron] ML2 plugin swallows mechanism driver exceptions

Rich Curran (rcurran) rcurran at cisco.com
Fri Jan 24 22:15:53 UTC 2014

Hi Paul -

I noticed the same issue a while back and looked into adding additional info (specific to the exception found in a mech driver) to the existing MechanismDriverError.

I ended up not going in that direction and starting coding up some additional common type mech driver exceptions in ml2/common/exceptions.py
+class ComputeHostNotConfigured(exceptions.NeutronException):
+class ConfigFailed(exceptions.NeutronException):
+class ConnectFailed(exceptions.NeutronException):
+class CredentialAlreadyExists(exceptions.NeutronException):

I was designing in this way so that these specific exceptions could then get mapped to different HTTP codes which are returned to the client. (This helps out when unit testing a mech driver. i.e. insert error code that generates one of the exception above and then look for the specific HTTP code listed below.)

Example code change from neutron/plugins/ml2/plugin.py
+from webob import exc as wexc
+from neutron.api.v2 import base

@@ -101,6 +103,7 @@ class Ml2Plugin(db_base_plugin_v2.NeutronDbPluginV2,
         self.type_manager = managers.TypeManager()
         self.mechanism_manager = managers.MechanismManager()
+        self._extend_fault_map()

+    def _extend_fault_map(self):
+        """Extends the Neutron Fault Map.
+        Exceptions specific to the ML2 Plugin are mapped to standard
+        HTTP Exceptions.
+        """
+        base.FAULT_MAP.update(
+            {ml2_exc.MissingRequiredFields: wexc.HTTPNotFound,
+             ml2_exc.ComputeHostNotConfigured: wexc.HTTPNotFound,
+             ml2_exc.CredentialAlreadyExists: wexc.HTTPBadRequest,
+             ml2_exc.ConnectFailed: wexc.HTTPServiceUnavailable,
+             ml2_exc.ConfigFailed: wexc.HTTPBadRequest})

(Obviously there are other changes that I haven't included here.)

I'm been working on other issues so haven't gotten back to sending this out for input/review.


From: Andre Pech [mailto:apech at aristanetworks.com]
Sent: Friday, January 24, 2014 4:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] ML2 plugin swallows mechanism driver exceptions

Hey Paul,

This is by design, and reraising a single MechanismDriverError was really to have a nice defined API for the MechanismManager class, avoid blanket try/except calls in the caller. But I do agree that it's really annoying to lose the information about the underlying exception. I like your idea of including the original exception text in the MechanismDriverError message, I think that'd help a lot.


On Fri, Jan 24, 2014 at 1:19 PM, Paul Ward <wpward at us.ibm.com<mailto:wpward at us.ibm.com>> wrote:

In implementing a mechanism driver for ML2 today, I discovered that any exceptions thrown from your mechanism driver will get swallowed by the ML2 manager (https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/managers.py at line 164).

Is this by design?  Sure, you can look at the logs, but it seems more user friendly to reraise the exception that got us here.  There could be multiple mechanism drivers being called in a chain, so changing this to reraise an exception that got us in trouble would really only be able to reraise the last exception encountered, but it seems that's better than none at all.  Or maybe even keep a list of exceptions raised and put all their texts into the MechanismDriverError message.


OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140124/171d495e/attachment.html>

More information about the OpenStack-dev mailing list