Re: [openstack-dev] [neutron] ML2 plugin swallows mechanism driver exceptions
FYI - I have pushed a change to gerrit for this: https://review.openstack.org/#/c/69748/ I went the simple route of just including the last exception encountered. All comments and reviews welcome!! Andre Pech ap...@aristanetworks.com wrote on 01/24/2014 03:43:24 PM: From: Andre Pech ap...@aristanetworks.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 01/24/2014 03:48 PM 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 wpw...@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. Thoughts? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] ML2 plugin swallows mechanism driver exceptions
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 OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 wpw...@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. Thoughts? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] ML2 plugin swallows mechanism driver exceptions
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:ap...@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.
Andre
On Fri, Jan 24, 2014 at 1:19 PM, Paul Ward
wpw...@us.ibm.commailto:wpw...@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.
Thoughts?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
