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
Example:
+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()
db.initialize()
+ 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.
Thanks,
Rich
From: Andre Pech [mailto:[email protected]]
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.
Andre
On Fri, Jan 24, 2014 at 1:19 PM, Paul Ward
<[email protected]<mailto:[email protected]>> 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.
Thoughts?
_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[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
