neutron/neutron/plugins/ml2
Ihar Hrachyshka 70727ba781 Merge remote-tracking branch 'origin/feature/qos' into merge-branch
Note to reviewers: gerrit diff for merge patches is very limited, and
leaving comments in global section won't scale, so please comment here:

https://etherpad.openstack.org/p/qos-merge-back-review

This merge commit introduces QoS feature into Liberty release of
Neutron.

The feature is documented in: doc/source/devref/quality_of_service.rst
included with the merge patch.

It includes:

- QoS API service plugin with QoS policy and QoS bandwidth limit
  (egress) rule support;
- core plugin mechanism to determine supported rule types, with its ML2
  implementation;
- new agent extension manager;
- QoS agent extension with pluggable backend QoS drivers (Open vSwitch
  and SR-IOV support is included).

To extend network and port core resources with qos_policy_id attribute,
a new ML2 extension driver (qos) was introduced that relies on the QoS
core resource extension (the idea is that eventually we'll get a core
resource extension manager that can be directly reused by core plugins).

Agent-server interaction is based on:

- get_device_details() method that is extended with qos_policy_id;
- a new push/pull mechanism that allows agents and servers to
  communicate using oslo.versionedobjects based objects sent on the
  wire.

The merge includes the following types of test coverage:

- unit tests;
- functional tests for OVS agent, QoS agent extension, and low level
  ovs_lib changes;
- API tests to cover port/network qos_policy_id attribute and new QoS
  resources.

The client changes can be found at:

* https://review.openstack.org/189655
* https://review.openstack.org/198277

The team also prepared fullstack test but it needs to wait for client
merge before it can pass in the gate:

* https://review.openstack.org/202492

Gerrit does not show diff for merge changes that did not result in any
conflict, so to facilitate review, rely on the following steps:

- fetch the patch locally
- git fetch origin
- git diff origin/master...

This merge also disables qos extension API tests until the service is
enabled in master gate.

Local changes apart from conflicts:
- updated down_revision for qos migration to reflect master expand head;
- disabled qos API tests with gate_hook.sh until we have it enabled in
  master gate;
- bumped oslo.versionedobjects requirement to reflect what is in
  openstack/requirements' global-requirements.txt

DocImpact
APIImpact
Partially-Implements: blueprint quantum-qos-api
Partially-Implements: blueprint ml2-qos
Partially-Implements: blueprint ml2-qos-ovs-bwlimiting
Partially-Implements: blueprint ml2-sriov-qos-with-bwlimiting
Change-Id: I92916d0e391791187e9a25ff172fb4b3504857b1
2015-08-17 15:16:55 +02:00
..
common Pass the extension driver exception to plugin 2015-08-12 09:36:04 +00:00
drivers Merge remote-tracking branch 'origin/feature/qos' into merge-branch 2015-08-17 15:16:55 +02:00
extensions Introduce base interface for core resource extensions 2015-08-07 21:36:15 +02:00
README Metaplugin removal 2015-07-23 19:05:05 +09:00
__init__.py Empty files should not contain copyright or license 2014-10-20 00:50:32 +00:00
config.py Added config variable for External Network type in ML2 2015-04-15 04:59:22 +00:00
db.py Switch to oslo_utils.uuidutils 2015-06-22 11:06:18 +00:00
driver_api.py Handle qos_policy on network/port create/update 2015-07-19 08:33:04 +02:00
driver_context.py Defer segment lookup in NetworkContext object 2015-06-09 04:47:07 +00:00
managers.py Pass the extension driver exception to plugin 2015-08-12 09:36:04 +00:00
models.py ML2: DB changes for hierarchical port binding 2015-02-13 23:30:25 -05:00
plugin.py Merge remote-tracking branch 'origin/feature/qos' into merge-branch 2015-08-17 15:16:55 +02:00
rpc.py Merge remote-tracking branch 'origin/feature/qos' into merge-branch 2015-08-05 17:15:40 +02: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. 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, and for vendor switches/controllers/etc.
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.