From: Bob Kukura Date: Mon, 7 Oct 2013 01:41:08 +0000 (-0400) Subject: Update ML2 README file for havana X-Git-Url: https://review.fuel-infra.org/gitweb?a=commitdiff_plain;h=2d7e2756271fff6413a572e11f9248465f23f1bb;p=openstack-build%2Fneutron-build.git Update ML2 README file for havana Closes-Bug: 1235308 Change-Id: I684581c00ff28bc9cdb36034a9a970275b0a0090 --- diff --git a/neutron/plugins/ml2/README b/neutron/plugins/ml2/README index 9e23fe84f..4dce789cb 100644 --- a/neutron/plugins/ml2/README +++ b/neutron/plugins/ml2/README @@ -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. - -Drivers within ml2 implement separately extensible sets of network +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 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. - -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. - -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. - -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 +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.