Embrane Neutron Plugin

Implements blueprint embrane-neutron-plugin

This commit implements the main Embrane plugin, which covers
route and extratoute extensions.

The plugin will rely on existing plugins for leveraging L2 networks,
for now it only supports OpenVSwitch and vlan networks, but more
supports are to come if the model is approved (or a different one
is suggested).

Change-Id: I90aff8ec4324bd3a7c59c411374db6a118d1a72b
Fixes formatting exception from logging in BigSwitch plugin

Corrects the data type expected for the HTTP code that comes
back from the back-end controller in a debug log call.

Closes-Bug: #1220521
Change-Id: Ic71b24c724222ade5e695addf291c6488d665da9
Add jump to float-snat chain after clearing snat chain

Clearing the chain in this code eliminates the rule to jump to the
floating-snat chain.  This is the simplest way to get it working
again.

Change-Id: Ic1818e10bd64170b6f0a2f52af8dc0814d7e04e0
Fixes: Bug #1218040
Add Neutron l3 metering agent

This is the agent side of :
blueprint bandwidth-router-measurement
blueprint bandwidth-router-label

This patch initiates agent side by adding a new
l3 metering agent and a Noop Driver.

DocImpact

Change-Id: Ib34721209c282b2669ff5488a33293d9f86467ef
Add method to get iptables traffic counters

Add methods to iptables_manager to get traffic counters.
this is a part of the blueprint bandwidth-router-measurement

Change-Id: I6485d1239085e46398126c81e674e399952a4597
Iptables metering driver

this is a part of the blueprint bandwidth-router-measurement

Change-Id: I37e4dc5abeaca4e13b32155bb7e2f07883ef9b2d
Implement MidoNet Neutron plugin for Havana

Implement L2, L3, security groups, metadata server support for
MidoNet Neutron plugin for Havana.

blueprint midonet-plugin-havana

Change-Id: I0dd1a2ca17d760443c4c7a464a66b6d0a2cf194a
Default to not capturing log output in tests

Viewing log output while tests are still running can be useful for
debugging, but log output was previously always captured.  This
change ensures that log capture is off by default, but can still
be enabled by setting OS_LOG_CAPTURE=1 in the shell environment.

testr invocation is unchanged and will continue to capture logs by
default.

Change-Id: I9d0fb648541280cacfebb47f67f608378ae66ef3
LBaaS integration with service type framework

The patch makes the following changes:

* adds new attribute of the pool: provider, which is provider name
as it is written in configuration
* adds support for multiple plugin drivers for loadbalancer
* cleans up healthmonitor-related plugin driver API
Drivers should work with healthmonitor associations only
* adds ability to update provider attribute for the pool used
to reassociate pools with new providers in case their providers
were removed from configuration

implements blueprint lbaas-integration-with-service-types

DocImpact

Change-Id: I4295c9bcceb38e60f813d5596af48bd8194c1c9b
ML2 type and mech managers should use instance vars for drivers lists

Fixes bug 1220296

The ML2 plugin's type and mechanism managers currently maintain
dictionaries/lists of type drivers, mechanism drivers, and ordered mechanism
drivers in (static) class variables. Once a type/mechanism/ordered-mechanism
driver of any given type is added to this list, then no new drivers of that
type are allowed to be registered, and therefore no new configuration for
that driver type is accepted.

This static nature of the driver dictionaries/lists is causing ML2 mechanism
driver unit test cases to fail. For example, if a non-vendor-specific ML2
plugin test case configures a VLAN type driver with no VLAN range, and then
a vendor specific test case attempts to configure a VLAN type driver with
some test VLAN range, then the new VLAN configuration is ignored because of
the previously (staticly) registered VLAN driver.

The proposed fix is to convert these driver dictionaries/lists to instance
variables, and clear them upon each instantiation of an ML2 type manager
or ML2 mechanism manager.

Change-Id: I3b5209640de229899561e2a3ec7c6dafe9a05e64
 Arista ML2 Mechanism driver

This patch implements Arista's modular L2 mechanism driver to
automate the management of virtual networks along with physical networks
using Arista hardware devices (Spine and Leaf switches)

This driver uses ML2 Mechanism Driver-API to interface with Neutron ML2 Plugin.

implements: blueprint arista-ml2-mechanism-driver

Change-Id: I1c4ca36cf3d7af013b7b3353e7b7d89fe39f91bf
Adding more unit tests for the FWaaS agent

Change-Id: Ic3de53ed9fa47f6518cbb25dac4ee7782c97bfbb
Fixes: bug #1215771
Merge "ML2 type and mech managers should use instance vars for drivers lists"
Refactoring for nicira plugin to support NVP DHCP/Metadata services

This initial patch is aimed at decoupling core plugin services from
DHCP and metadata services. The abstraction being introduced is
needed so that the code can support both models where dhcp and
metadata services are provided by external RPC agents or solely by
the server-side plugin.

Supports blueprint nvp-dhcp-metadata-services

Change-Id: I396ee7bbcbd866e4e9d4a79887e844b4f5ec3c9e
Implement ML2 port binding

The ml2 plugin uses mechanism drivers to determine which network
segment and what VIF driver to use for a port. Mechanism drivers
supporting the openvswitch, linuxbridge, and hyperv agents are
added. The binding:host attribute is set on ports belonging to the
dhcp and l3 agents so that they can be bound.

To use with devstack until it is updated, set
"Q_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch,linuxbridge" in localrc.

The hyperv L2 agent does not currently implement the agents_db RPC,
and will therefore not work with its ml2 mechanism driver. This issue
will be tracked as a bug to be fixed in a separate merge.

implements blueprint: ml2-portbinding

Change-Id: Icb9c70d8b0d7fcb34b57adc760bb713b740e5dad
Merge "LBaaS integration with service type framework"
Merge "Default to not capturing log output in tests"
Merge "Refactoring for nicira plugin to support NVP DHCP/Metadata services"
Verify MTU is valid for ipsec_site_connection

Since the check relies on the vpnservice subnet to determine whether
this is IPv4 ro IPv6, we must check in the plugin. Test is done at
create/update time and ensures that the MTU is equal to or greater
than the minimum allowed values, which are set to 68 for IPv4
minimum and 1280 for IPv6, respectively.

Refactored code to allow reuse of create and update test functions,
by allowing tests to override some settings, and to provide a dict
of changed items (for update).

bug 1219489

Change-Id: I3e62ef786d3a02c761903a15d546ee8758c0bf7f
Introduce periodic state synchronization with backend

Blueprint nicira-plugin-get-improvements

With this patch GET operations on the Nicira plugin will not
be forwarded anymore to the NVP backend.
Resource operational status will be periodically retrieved from
the NVP backend using a DynamicLoopingCall.
The process has been designed with the aim of avoiding:
1) frequent queries to NVP for retrieving resource status
2) execution of large queries to NVP for retrieving the status
   of a consistent number of resources.
The process can be tuned using a set of configuration variables.
GET operations will now return a status which might differ
from the actual status of the resource. For retrieving status
in a punctual way, the field 'status' should be explicitly
specified in the GET request (only 'show' support has been
implemented in this patch)

This patchs also makes some changes to the fake nvp api client in
order to ensure each instance has a private set of dictionaries for
fake nvp entities.

Change-Id: Ia745b80d2826de32ba8d6883c0d6e0893047e123