feecaacb0f
Fixes bug 1220296 The ML2 plugin's type and mechanism managers currently maintain dictionaries/lists of type drivers, mechanism drivers, and ordered mechanism drivers in (static) class variables. Once a type/mechanism/ordered-mechanism driver of any given type is added to this list, then no new drivers of that type are allowed to be registered, and therefore no new configuration for that driver type is accepted. This static nature of the driver dictionaries/lists is causing ML2 mechanism driver unit test cases to fail. For example, if a non-vendor-specific ML2 plugin test case configures a VLAN type driver with no VLAN range, and then a vendor specific test case attempts to configure a VLAN type driver with some test VLAN range, then the new VLAN configuration is ignored because of the previously (staticly) registered VLAN driver. The proposed fix is to convert these driver dictionaries/lists to instance variables, and clear them upon each instantiation of an ML2 type manager or ML2 mechanism manager. Change-Id: I3b5209640de229899561e2a3ec7c6dafe9a05e64
# -- Welcome!
You have come across a cloud computing network fabric controller. It has identified itself as "Neutron." It aims to tame your (cloud) networking!
# -- External Resources:
The homepage for Neutron is: http://launchpad.net/neutron . Use this site for asking for help, and filing bugs. Code is available on github at <http://github.com/openstack/neutron>.
The latest and most in-depth documentation on how to use Neutron is available at: <http://docs.openstack.org>. This includes:
Neutron Administrator Guide http://docs.openstack.org/trunk/openstack-network/admin/content/
Neutron API Reference: http://docs.openstack.org/api/openstack-network/2.0/content/
The start of some developer documentation is available at: http://wiki.openstack.org/NeutronDevelopment
For help using or hacking on Neutron, you can send mail to <mailto:openstack-dev@lists.openstack.org>.