neutron/neutron/plugins/ml2
Robert Kukura a57dc2c30a ML2: Remove validate_port_binding() and unbind_port()
The API implemented by ML2 mechanism drivers included three methods
related to port binding that were called within DB transactions, but
that could potentially involve communication with controllers or
devices that should not be done within transactions. A subsequent
patch will move the calls to bind_port() outside of tranactions. This
patch eliminates the other two methods from the MechanismDriver API.

The validate_port_binding() method was previously called on the bound
mechanism driver to check whether an existing binding was still valid,
so that the port could be rebound if something changed. But since nova
has no way to handle changes to binding:vif_type or
binding:vif_details after a port is initially plugged, this turned out
not to be useful, so the method has been removed from the
MechanismDriver API. Now, once a port is successfully bound, the
binding remains until the port is deleted or any of it's
binding:host_id, binding:vnic_type, or binding:profile attribute
values are changed.

The unbind_port() method was previously called on the bound mechanism
driver as an existing binding was removed. This method was not used by
any existing mechanism drivers, and was redundant with the
update_port_precommit() and update_port_postcommit() methods that are
called on all mechanism drivers when an existing binding is removed,
so this method has also been removed from the driver API.

Eliminating the unbind_port() call allows the binding details to be
made available via the PortContext in delete_port_postcommit() calls,
completing the resolution of bug 1276395.

Closes-bug: 1276395
Partial-bug: 1276391
Change-Id: I70fb65b478373c4f07f5273baa097fc50e5ba2ef
2014-03-20 10:03:46 -04:00
..
common Initial Modular L2 Mechanism Driver implementation. 2013-07-10 18:16:03 -07:00
drivers ML2: Remove validate_port_binding() and unbind_port() 2014-03-20 10:03:46 -04:00
README Update ML2 README file for havana 2013-10-06 22:55:01 -04:00
__init__.py Rename Quantum to Neutron 2013-07-06 15:02:43 -04:00
config.py Merge "Register agent schedulers options in one place" 2013-07-18 10:05:43 +00:00
db.py Implement Mellanox ML2 MechanismDriver 2014-03-03 22:43:10 +02:00
driver_api.py ML2: Remove validate_port_binding() and unbind_port() 2014-03-20 10:03:46 -04:00
driver_context.py ML2 mechanism driver access to binding details 2014-02-26 09:16:07 -05:00
managers.py ML2: Remove validate_port_binding() and unbind_port() 2014-03-20 10:03:46 -04:00
models.py ML2 binding:profile port attribute 2014-02-24 12:30:46 -05:00
plugin.py ML2: Remove validate_port_binding() and unbind_port() 2014-03-20 10:03:46 -04:00
rpc.py Send fdb remove message when a port is migrated 2014-03-14 10:17:55 +01:00

README

The Modular Layer 2 (ML2) plugin is a framework allowing OpenStack
Networking to simultaneously utilize the variety of layer 2 networking
technologies found in complex real-world data centers. It supports the
Open vSwitch, Linux bridge, and Hyper-V L2 agents, replacing and
deprecating the monolithic plugins previously associated with those
agents, and can also support hardware devices and SDN controllers. The
ML2 framework is intended to greatly simplify adding support for new
L2 networking technologies, requiring much less initial and ongoing
effort than would be required for an additional monolithic core
plugin. It is also intended to foster innovation through its
organization as optional driver modules.

The ML2 plugin supports all the non-vendor-specific neutron API
extensions, and works with the standard neutron DHCP agent. It
utilizes the service plugin interface to implement the L3 router
abstraction, allowing use of either the standard neutron L3 agent or
alternative L3 solutions. Additional service plugins can also be used
with the ML2 core plugin.

Drivers within ML2 implement separately extensible sets of network
types and of mechanisms for accessing networks of those types. Unlike
with the metaplugin, multiple mechanisms can be used simultaneously to
access different ports of the same virtual network. Mechanisms can
utilize L2 agents via RPC and/or interact with external devices or
controllers. By utilizing the multiprovidernet extension, virtual
networks can be composed of multiple segments of the same or different
types. Type and mechanism drivers are loaded as python entrypoints
using the stevedore library.

Each available network type is managed by an ML2 type driver.  Type
drivers maintain any needed type-specific network state, and perform
provider network validation and tenant network allocation. As of the
havana release, drivers for the local, flat, vlan, gre, and vxlan
network types are included.

Each available networking mechanism is managed by an ML2 mechanism
driver. All registered mechanism drivers are called twice when
networks, subnets, and ports are created, updated, or deleted. They
are first called as part of the DB transaction, where they can
maintain any needed driver-specific state. Once the transaction has
been committed, they are called again, at which point they can
interact with external devices and controllers. Mechanism drivers are
also called as part of the port binding process, to determine whether
the associated mechanism can provide connectivity for the network, and
if so, the network segment and VIF driver to be used. The havana
release includes mechanism drivers for the Open vSwitch, Linux bridge,
and Hyper-V L2 agents, for Arista and Cisco switches, and for the
Tail-f NCS. It also includes an L2 Population mechanism driver that
can help optimize tunneled virtual network traffic.

For additional information regarding the ML2 plugin and its collection
of type and mechanism drivers, see the OpenStack manuals and
http://wiki.openstack.org/wiki/Neutron/ML2.