x/vmware-nsx
Code Issues Proposed changes

Update ML2 README file for havana

Browse Source 
Closes-Bug: 1235308
Change-Id: I684581c00ff28bc9cdb36034a9a970275b0a0090
This commit is contained in:
Bob Kukura 2013-10-06 21:41:08 -04:00
parent c1678e4f1a
commit 2d7e275627
1 changed files with 45 additions and 76 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

121
neutron/plugins/ml2/README
View File

@ -1,84 +1,53 @@
The Modular Layer 2 (ml2) plugin is a framework allowing OpenStack The Modular Layer 2 (ML2) plugin is a framework allowing OpenStack
Networking to simultaneously utilize the variety of layer 2 networking Networking to simultaneously utilize the variety of layer 2 networking
technologies found in complex real-world data centers. It currently technologies found in complex real-world data centers. It supports the
works with the existing openvswitch, linuxbridge, and hyperv L2 Open vSwitch, Linux bridge, and Hyper-V L2 agents, replacing and
agents, and is intended to replace and deprecate the monolithic deprecating the monolithic plugins previously associated with those
plugins associated with those L2 agents. The ml2 framework is also agents, and can also support hardware devices and SDN controllers. The
intended to greatly simplify adding support for new L2 networking ML2 framework is intended to greatly simplify adding support for new
technologies, requiring much less initial and ongoing effort than L2 networking technologies, requiring much less initial and ongoing
would be required to add a new monolithic core plugin. 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.
Drivers within ml2 implement separately extensible sets of network 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 types and of mechanisms for accessing networks of those types. Unlike
with the metaplugin, multiple mechanisms can be used simultaneously to with the metaplugin, multiple mechanisms can be used simultaneously to
access different ports of the same virtual network. Mechanisms can access different ports of the same virtual network. Mechanisms can
utilize L2 agents via RPC and/or use mechanism drivers to interact utilize L2 agents via RPC and/or interact with external devices or
with external devices or controllers. Virtual networks can be composed controllers. By utilizing the multiprovidernet extension, virtual
of multiple segments of the same or different types. Type and networks can be composed of multiple segments of the same or different
mechanism drivers are loaded as python entrypoints using the stevedore types. Type and mechanism drivers are loaded as python entrypoints
library. using the stevedore library.
Each available network type is managed by an ml2 TypeDriver. Each available network type is managed by an ML2 type driver. Type
TypeDrivers maintain any needed type-specific network state, and drivers maintain any needed type-specific network state, and perform
perform provider network validation and tenant network allocation. The provider network validation and tenant network allocation. As of the
initial ml2 version includes drivers for the local, flat, vlan, gre, havana release, drivers for the local, flat, vlan, gre, and vxlan
and vxlan network types. network types are included.
RPC callback and notification interfaces support interaction with L2, Each available networking mechanism is managed by an ML2 mechanism
DHCP, and L3 agents. This version has been tested with the existing driver. All registered mechanism drivers are called twice when
openvswitch and linuxbridge plugins' L2 agents, and should also work networks, subnets, and ports are created, updated, or deleted. They
with the hyperv L2 agent. A modular agent may be developed as a are first called as part of the DB transaction, where they can
follow-on effort. 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.
Support for mechanism drivers is currently a work-in-progress in For additional information regarding the ML2 plugin and its collection
pre-release Havana versions, and the interface is subject to change of type and mechanism drivers, see the OpenStack manuals and
before the release of Havana. MechanismDrivers are currently called http://wiki.openstack.org/wiki/Neutron/ML2.
both inside and following DB transactions for network and port
create/update/delete operations. In a future version, they will also
called to establish a port binding, determining the VIF type and
network segment to be used.
The database schema and driver APIs support multi-segment networks,
but the client API for multi-segment networks is not yet implemented.
ML2 supports devstack at the moment with either the Open vSwitch or
LinuxBridge L2 agents for local, flat, vlan, or gre network types.
Note that ml2 does not yet work with nova's GenericVIFDriver, so it is
necessary to configure nova to use a specific driver compatible with
the L2 agent deployed on each compute node. Additionally, support for
configuring additional ML2 items is a work in progress in devstack.
This includes configuring VXLAN support for ML2 with the OVS agent.
Note that the ml2 plugin is new and should be conidered experimental
at this point. It is undergoing rapid development, so driver APIs and
other details are likely to change during the havana development
cycle.
Follow-on tasks required for full ml2 support in havana, including
parity with the existing monolithic openvswitch, linuxbridge, and
hyperv plugins:
- Additional unit tests
- Implement MechanismDriver port binding so that a useful
binding:vif_type value is returned for nova's GenericVIFDriver based
on the binding:host_id value and information from the agents_db
Additional follow-on tasks expected for the havana release:
- Extend providernet extension API to support multi-segment networks
The following MechanismDrivers are actively under development for the
Havana release:
- Arista Driver:
https://blueprints.launchpad.net/quantum/+spec/sukhdev-8
- Cisco Nexus Driver:
https://blueprints.launchpad.net/quantum/+spec/ml2-md-cisco-nexus
- OpenDaylight Driver:
https://blueprints.launchpad.net/quantum/+spec/ml2-opendaylight-mechanism-driver
- Tail-f NCS Driver:
https://blueprints.launchpad.net/quantum/+spec/tailf-ncs