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
mailto: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] [networking][ml2] Device configuration
Hi All - Regarding the configuration (ml2_conf.ini) of mechanism devices. Cisco defines external devices in our INI file like this: # Nexus Switch Format. # [NEXUS_SWITCH:] # = <- for cisco nexus devices a port would be in the form "/" # ssh_port= # username= <- used as login username to the switch # password= <- password for that username Any thoughts on how we want to define this configuration info under ML2? The simplest solution is to have separate INI sections for each vendor/device. Ex. [CISCO_NEXUS:] Variables defined only for cisco nexus devices [ARISTA_XYZ] Whatever you want. Note that the cisco INI file can define more than one NEXUS_SWITCH section (different IPs). We could think about creating more generic section headers but would need a variable telling us what device owns that section. Ex. [ML2_MECH_DEVICE:] variable1 = variable2 = type = cisco_nexus The cisco config.py file doesn't have default values for these sections. At init time we create a dictionary of these devices. Thoughts? Thanks, Rich ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [networking][ml2] Common files (was: Device configuration)
Hi All - Some light reading and softball questions for a Friday afternoon. Here are some common files that the cisco mech driver (and I'm assuming the other mechanism drivers) will need to start off. common/exceptions.py common/constants.py We might even want to consider moving config.py into the common/ directory. In the Cisco (sub)plugin we have some specific DB requirements. I'm thinking we may want a db/ directory also. XML vendor specific strings. Store under common/snippets_"vendorname".py? How do we want to abbreviate mechanism driver files? md, mech_driver, mdriver, mech (contrasting to "type_xyz" drivers) Thanks, Rich From: Andre Pech [mailto:ap...@aristanetworks.com] Sent: Wednesday, June 19, 2013 12:24 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [networking][ml2] Device configuration I don't feel too strongly either way. It seems like mechanism drivers will have distinct sets of variables, so having a common subsection name may be confusing. Plus I like the clarity of the type of the mechanism driver being in the section name rather than hidden in a type name. Maybe we prepend ML2_MECH to that to make it clear that these are variables for mechanism drivers? Something like: [ML2_MECH_CISCO_NEXUS: ... [ML2_MECH_ARISTA:] ... As I said before, am fine with either of the proposals below too. Andre On Wed, Jun 19, 2013 at 8:59 AM, Rich Curran (rcurran) mailto:rcur...@cisco.com>> wrote: Hi All - Regarding the configuration (ml2_conf.ini) of mechanism devices. Cisco defines external devices in our INI file like this: # Nexus Switch Format. # [NEXUS_SWITCH:] # = <- for cisco nexus devices a port would be in the form "/" # ssh_port= # username= <- used as login username to the switch # password= <- password for that username Any thoughts on how we want to define this configuration info under ML2? The simplest solution is to have separate INI sections for each vendor/device. Ex. [CISCO_NEXUS:] Variables defined only for cisco nexus devices [ARISTA_XYZ] Whatever you want. Note that the cisco INI file can define more than one NEXUS_SWITCH section (different IPs). We could think about creating more generic section headers but would need a variable telling us what device owns that section. Ex. [ML2_MECH_DEVICE:] variable1 = variable2 = type = cisco_nexus The cisco config.py file doesn't have default values for these sections. At init time we create a dictionary of these devices. Thoughts? Thanks, Rich ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto: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] devstack with ml2 setup problem
Hi Luke - Make sure you have the latest devstack which contains the ml2 hooks. Remove the comments on the ML2 info below. Note that the mech driver keyword for the logger is "logger", not "log". Thanks, Rich From: Luke Gorrie [mailto:l...@tail-f.com] Sent: Friday, September 06, 2013 11:33 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [Neutron] devstack with ml2 setup problem Howdy! I'm trying to get ml2 up and running with devstack. I'm falling at the first hurdle - getting devstack working with Neutron. I would love a hint! Here is my localrc: disable_service n-net enable_service q-svc enable_service q-agt enable_service q-dhcp enable_service q-l3 enable_service q-meta enable_service neutron # Optional, to enable tempest configuration as part of devstack #enable_service tempest #Q_PLUGIN=ml2 #ENABLE_TENANT_VLANS=True #ML2_VLAN_RANGES=mynetwork:100:200 #Q_ML2_PLUGIN_MECHANISM_DRIVERS=log,ncs DATABASE_PASSWORD=admin RABBIT_PASSWORD=admin SERVICE_TOKEN=admin SERVICE_PASSWORD=admin ADMIN_PASSWORD=admin but after firing up stack and logging into the GUI the system seems not entirely healthy and I see messages like: Error: Unauthorized: Unable to retrieve usage information. Error: Unauthorized: Unable to retrieve limit information. Error: Unauthorized: Unable to retrieve project list. It had looked okay before I tried enabled Neutron. This is with Ubuntu raring in vagrant/virtualbox with 2GB RAM. Any tips appreciated! -Luke ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Fwd: [Neutron] ML2 + Nexus :: update_port_precommit ERROR
Hi Adam – Please email me directly w/ the log information. Thanks, Rich From: Adam Lawson [mailto:alaw...@aqorn.com] Sent: Sunday, March 01, 2015 11:02 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] Fwd: [Neutron] ML2 + Nexus :: update_port_precommit ERROR Hello, Sending this message to the dev group instead since I may be running into a bug (https://bugs.launchpad.net/neutron/+bug/1247976/+activity). I'm running Icehouse (modules come up as 2014.1.3 generally). Thoughts? Adam Lawson AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 [http://www.aqorn.com/images/logo.png] -- Forwarded message -- From: Adam Lawson mailto:alaw...@aqorn.com>> Date: Sat, Feb 28, 2015 at 2:30 PM Subject: [Neutron] ML2 + Nexus :: update_port_precommit ERROR To: openstack mailto:openst...@lists.openstack.org>> I'm experimenting with OpenStack Icehouse with a dedicated Network node using the ML2 plugin, cisco_nexus mechanism driver and seeing Neutron errors relating to update_port_precommit and delete_port_precommit. Defined type driver is VLAN. Problem is being unable to boot instances using Private or Public networks. Is this a known bug when using ML2 with Cisco Nexus switches or is it resolvable? Has anyone else run into this? Mahalo, Adam Adam Lawson AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 [http://www.aqorn.com/images/logo.png] __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
