Update ML2 README file for havana
Closes-Bug: 1235308 Change-Id: I684581c00ff28bc9cdb36034a9a970275b0a0090
This commit is contained in:
Bob Kukura
parent
c1678e4f1a
commit
2d7e275627
@ -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
|
||||
technologies found in complex real-world data centers. It currently
|
||||
works with the existing openvswitch, linuxbridge, and hyperv L2
|
||||
agents, and is intended to replace and deprecate the monolithic
|
||||
plugins associated with those L2 agents. The ml2 framework is also
|
||||
intended to greatly simplify adding support for new L2 networking
|
||||
technologies, requiring much less initial and ongoing effort than
|
||||
would be required to add a new monolithic core plugin.
|
||||
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.
|
||||
|
||||
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
|
||||
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 use mechanism drivers to interact
|
||||
with external devices or controllers. 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.
|
||||
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 TypeDriver.
|
||||
TypeDrivers maintain any needed type-specific network state, and
|
||||
perform provider network validation and tenant network allocation. The
|
||||
initial ml2 version includes drivers for the local, flat, vlan, gre,
|
||||
and vxlan network types.
|
||||
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.
|
||||
|
||||
RPC callback and notification interfaces support interaction with L2,
|
||||
DHCP, and L3 agents. This version has been tested with the existing
|
||||
openvswitch and linuxbridge plugins' L2 agents, and should also work
|
||||
with the hyperv L2 agent. A modular agent may be developed as a
|
||||
follow-on effort.
|
||||
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.
|
||||
|
||||
Support for mechanism drivers is currently a work-in-progress in
|
||||
pre-release Havana versions, and the interface is subject to change
|
||||
before the release of Havana. MechanismDrivers are currently called
|
||||
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
|
||||
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.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user