bug fix restart quantum-plugin-openvswitch-agent

In the cookbook-openstack-network/recipes/common.rb, for "openvswitch",
it restarts the service quantum-plugin-openvswitch-agent whether or not
that service is running.  The service would only be running if the openvswitch
recipe was also included.

Fixes: Bug #1210400
Implements: make the restart quantum-plugin-openvswitch-agent conditional

Change-Id: I8801450ac88547e5961bb37f0d1b7c002671c9e8
Add allow_overlapping_ips parameter toggle

Change-Id: Icc29933b1ffa24a117625c7e0d8ced4954a62d32
Add syslog logging to quantum-ha-tool

Add syslog logging to quantum-ha-tool and direct
any output from the command to /dev/null so we do
not generate output to cron

Change-Id: I225dd90252a4a54b4bdab05a98068ca4e06903f0
Merge "bug fix restart quantum-plugin-openvswitch-agent"
Merge "Add syslog logging to quantum-ha-tool"
Merge "Add allow_overlapping_ips parameter toggle"
Bug fix pyparsing upgrade for python quantum client

The python-quantumclient package may not include the correct
version of pyparsing in its dependencies, requiring us to
ensure that it is upgraded to the latest version prior to usage.
Needed to correct tests to pass openstack-common 0.4.0 changes.

Change-Id: Ia8507a5fe94322ff3106d12d161dcedf2ee19fdd
Add NIC offload disable feature

On some ubuntu kernels with some versions
of Openvswitch and Nicira, when NIC offloading
is enabled on the adapter, the kernel may OOPS
within the openvswitch module.  There is now a flag
to attempt to disable all offload settings for the
adapter prior to openvswitch service startup.

Change-Id: I61b195c69fbb827876de1c3537cece01f36c6db0
The DHCP build process will pin the version

Without setting the version, we end up with a dnsmasq
binary that reports an UNKNOWN version which quantum
raises an exception on

Change-Id: Ie1970b9526be1d6151a7eb08a2686be368239193
don't install any plugin packages on SUSE

Change-Id: Icb08473c8bb41e56e34ce6f51983b3195d631d11
Allow downgrading guest MTU settings

Most standard networks will have a 1500 MTU sized
provider network.  Because there is a 24 byte overhead
with using any kind of encapsulation, most users will
want to downgrade the MTU set within their guests or
raise their internal network MTU above 1500.  The former
is much easier to do and has been added as an option to
dnsmasq that is passed to the client.

Change-Id: I199ec6e46c114d0277230eded002ad99786c061c
Merge "Allow downgrading guest MTU settings"