Check new segments added to OVN mechanism driver. This mechanism
driver does not inherit from ``SimpleAgentMechanismDriverBase``
because OVN has no agents (NOTE 1). However OVN mechanism driver
requires an OVN controller service in each deployed chassis. This
is how OVN driver knows the hosts using this backend.
The segments, attached to an external network (connected to a
physical network), can be mapped to a host if ther is a chassis (OVN
controller agent) in this host.
NOTE 1: OVN provides agent API compatibility, presenting the
controller and the metadata services as agents. But OVN mechanism
driver has no control or provides any information (via RPC) to
those services.
Closes-Bug: #1949967
Change-Id: I570b2251da8a4a25d155ba838346b24afafd727f
This change adds VNIC type vDPA ("vdpa") to the list of
supported VNIC types for the OVS and OVN mech drivers.
Depends-On: https://review.opendev.org/#/c/760043/
Change-Id: If22aedc147f7e2256f8f8ad3bebb80b6bb2f6d3d
There is no real reason we should be using some of the
terms we do, they're outdated, and we're behind other
open-source projects in this respect. Let's switch to
using more inclusive terms in all possible places.
Change-Id: I99913107e803384b34cbd5ca588451b1cf64d594
Now that we use setproctitle for neutron-server workers (and
neutron-keepalived-state-change), this has the side effect of changing
the process name for agents, impacting some monitoring systems. More
details in launchpad bug.
This patch fixes it by setting the name with setproctitle to:
agent name (original process name).
Also use the newly introduced name constants to replace existing
hardcoded uses.
Change-Id: I74c3a4d3e9f833752571a75f196560cd45529385
Closes-Bug: #1881297
Back in Newton, patch [1] added to the agents possibility to report in
the heartbeat messages if hybrid plug of the ports is required or not.
Usage of "firewall_driver" option by mechanism drivers (so on the
server's side) was kept just for backward compatibility.
But as we are now about 4 years from the [1] I think it should be safe
to do small cleaning, remove usage of this option in the neutron server
and not confuse users where this config option has to be set and why.
[1] https://review.opendev.org/#/c/311814/
Change-Id: I2ccc4c8784c64858acaa3c3431cf9a3d13e5e154
Now that we are python3 only, we should move to using the built
in version of mock that supports all of our testing needs and
remove the dependency on the "mock" package.
This patch moves all references to "import mock" to
"from unittest import mock". It also cleans up some new line
inconsistency.
Fixed an inconsistency in the OVSBridge.deferred() definition
as it needs to also have an *args argument.
Fixed an issue where an l3-agent test was mocking
functools.partial, causing a python3.8 failure.
Unit tests only, removing from tests/base.py affects
functional tests which need additional work.
Change-Id: I40e8a8410840c3774c72ae1a8054574445d66ece
Removed E125 (continuation line does not distinguish itself
from next logical line) from the ignore list and fixed all
the indentation issues. Didn't think it was going to be
close to 100 files when I started.
Change-Id: I0a6f5efec4b7d8d3632dd9dbb43e0ab58af9dff3
Added "connectivity" parameter to mech driver vif_details. The default
value is "legacy". The in-tree drivers (Linux Bridge, Open vSwitch, SR-IOV
and MacVTap) have "l2" connectivity.
Change-Id: I45480986fc89e0b2f475ee0ceb13d8742fb8c530
Related-Bug: #1821058
Adds support for OVS DPDK port representors[1], a direct port on
a netdev datapath is considered a DPDK representor port.
get_vif_type returns OVS VIF type in case of a direct port.
[1] http://docs.openvswitch.org/en/latest/topics/dpdk/phy/#representors
Closes-Bug: #1829734
Change-Id: I3956eeda19ebc93fdb0b13c1cfb3dc64abffee9f
In case of Smart NIC vNIC type neutron should mimic nova-compute
that plug the port to the ovs bridge.
Extend the Neutron OVS mechanism driver and Neutron OVS Agent to bind
the Neutron port for the baremetal host with Smart NIC. This will allow
the Neutron OVS Agent to configure the pipeline of the OVS running on
the Smart NIC and leverage the pipeline features such as: VXLAN,
Security Groups and ARP Responder.
Story: #2003346
Closes-Bug: #1785608
Change-Id: I6d520d3bac2e9ceb30b5b6197c6eb0f958cc3659
Drive the choice of mechanism driver during binding as inferred from
the resource provider allocated by nova and as told to neutron via the
port's binding:profile.
As discussed on a neutron qos irc meeting some time ago
this patch introduces a new assumption on bind_port() implementations.
That is an implementation of bind_port() in any mech driver supporting
Guaranteed Minimum Bandwidth bind_port() must not have a non-idempotent
side effect. Because the last binding level will be redone for a 2nd
time with a narrowed down list of mechanism drivers. And if the 2nd call
does not give the same result as the first all kind of weird things can
happen.
Change-Id: I2b7573ec6795170ce45a13d5d0ad7844fb85182d
Depends-On: https://review.openstack.org/574781
Depends-On: https://review.openstack.org/635160
Partial-Bug: #1578989
See-Also: https://review.openstack.org/502306 (nova spec)
See-Also: https://review.openstack.org/508149 (neutron spec)
get_mappings for machanism drivers return back different dicts for
different mechanism drivers. By adding get_standard_device_mappings
method SRIOV and OVS mechanism drivers can return a mapping dict in a
form like this one:
{'physnet_name': ['device_or_bridge_1', 'device_or_bridge_2']}
Change-Id: Ieddd9b3a4f3d7269aafc373f040c55b025f5c201
Related-Bug: #1578989
Now supported_vnic_types is hardcoded to the mechanism drivers, but that
can depend on several factors, like type of the NIC, admin decision,
etc.
With this patch we put the right to decide which vnic types are
supported for ovs agent into the hands of the admin, by allowing
blacklisting items from the mechanism driver specific list.
Background: http://eavesdrop.openstack.org/meetings/neutron_qos/2018/
neutron_qos.2018-07-31-15.00.log.html#l-58
Change-Id: I63e562e2eccc5b02c1c767d6a2c28cb803131e99
Partial-Bug: #1578989
See-Also: https://review.openstack.org/502306 (nova spec)
See-Also: https://review.openstack.org/508149 (neutron spec)
- This change updates _set_bridge_name to set
the bridge name field in the vif binding details.
- This change adds the integration_bridge name
to the agent configuration report.
Change-Id: I454efcb226745c585935d5bd1b3d378f69a55ca2
Closes-Bug: #1788009
This patch switches callbacks over to the payload object style events
[1] for BEFORE_READ based notifications. To do so an EventPayload object
is used with the publish() method to pass along the API related data.
In addition a few UTs are updated to work with the changes.
NeutronLibImpact
[1] https://docs.openstack.org/neutron-lib/latest/contributor/callbacks.html#event-payloads
Change-Id: Iff3e96c56867b4bf4272fed676f39cd6796d756c
In I77650be5f04775a72e2bdf694f93988825a84b72 we added
vnic_type direct to the ovs mechanism drivers supported
vnic_types. This cause problems when working with ovs and sriovnicswitch
mechanism drivers in that order. In this case the ovs will bind
the direct port instead of the sriovnicswitch.
This change make ovs mech driver to bind the direct port only
if user requested --binding-profile '{"capabilities": ["switchdev"]}'
in the direct port if a user don't request this capability the SR-IOV
legacy NIC mode is used.
When enable-sriov-nic-features will be implemented in nova and
libvirt will expose the switchdev capability then nova will be
able to select a host which supports SR-IOV nic with switchdev
mode.
[1] - https://review.openstack.org/#/c/435954/11/specs/pike/approved/enable-sriov-nic-features.rst
[2] - https://www.redhat.com/archives/libvir-list/2017-August/msg00583.html
Closes-Bug: #1713590
Change-Id: I0b5f062bcbf02381bdf4f694fc039f9bb17a2db5
Added datapath_type to vif_details returned by OVS
mech driver.
Depends-On: Ie523c821995c046c7f77783a34e75053fc0abb3d
Partial-Bug: #1632372
Change-Id: Ief83150caf1a32a2c043b0245b36e5ebc3a16379
In Kernel 4.8 we introduced Traffic Control (TC see [1]) hardware offloads
framework for SR-IOV VFs which allows us to configure the NIC [2].
Subsequent OVS patches [3] allow us to use the TC framework
to offload OVS datapath rules.
This patch allow OVS mech driver to bind direct (SR-IOV) port.
This will allow to offload the OVS flows using tc to the SR-IOV NIC
and gain accelerate OVS.
[1] https://linux.die.net/man/8/tc
[2] http://netdevconf.org/1.2/papers/efraim-gerlitz-sriov-ovs-final.pdf
[3] https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/330606.html
DocImpact: Add SR-IOV offload support for OVS mech driver
Partial-Bug: #1627987
Depends-On: I6bc2539a1ddbf7990164abeb8bb951ddcb45c993
Change-Id: I77650be5f04775a72e2bdf694f93988825a84b72
The ml2 MechanismDriver is now in neutron-lib along with its associated
constants. This patch switches over to the lib versions of those, but
leaves a shim of the MechanismDriver that just ref's the driver from
lib. This shim allows our broad consumer base of the driver to switch
over at their leisure.
NeutronLibImpact
Change-Id: I99e3de6d933a1bb341394f85415fb07306a82a01
This moves the get_vif_type hook point from OVS into the mech agent
base so other mechanism drivers can also return different VIF types
depending on the context of the binding.
This will be used by linux bridge in change
I23c5faaeab69aede1fd038a36f4a0b8f928498ce.
Change-Id: I3b695909c954158df90f436a7ed259890977d25a
The callback modules have been available in neutron-lib since commit [1]
and are ready for consumption.
As the callback registry is implemented with a singleton manager
instance, sync complications can arise ensuring all consumers switch to
lib's implementation at the same time. Therefore this consumption has
been broken down:
1) Shim neutron's callbacks using lib's callback system and remove
existing neutron internals related to callbacks (devref, UTs, etc.).
2) Switch all neutron's callback imports over to neutron-lib's.
3) Have all sub-projects using callbacks move their imports over to use
neutron-lib's callbacks implementation.
4) Remove the callback shims in neutron-lib once sub-projects are moved
over to lib's callbacks.
5) Follow-on patches moving our existing uses of callbacks to the new
event payload model provided by neutron-lib.callback.events
This patch implements #2 from above, moving all neutron's callback
imports to use neutron-lib's callbacks.
There are also a few places in the UT code that still patch callbacks,
we can address those in step #4 which may need [2].
NeutronLibImpact
[1] fea8bb64ba7ff52632c2bd3e3298eaedf623ee4f
[2] I9966c90e3f90552b41ed84a68b19f3e540426432
Change-Id: I8dae56f0f5c009bdf3e8ebfa1b360756216ab886
Neutron-lib 1.1.0 is now out and contains the portbindings
API definition (as per commit [1]). This patch moves neutron
references over to the neutron-lib version.
NeutronLibImpact
- Consumers using the public constants within neutron's
portbindings API extension must now use the values
from neutron-lib.
[1] 87e42f993c07ae320159d5123662ee9f3bd4d903
Change-Id: I669af9b4c712877772d91a03857ab108714001d4
- vhost-user reconnect is a new feature added
in dpdk 16.07 and qemu 2.7.
- vhost-user reconnect allows VMs using vhost-user
interfaces to reconnect to the vhost-user backend if
the backend terminates either as a result of a graceful
shutdown or a crash with out requiring the vm to reboot.
- vhost-user reconnect requires qemu to be the vhost-user server
and ovs to be the client.
- dpdk prior to 16.07 only supports qemu client/ dpdk server mode.
- This change extends the ovs mech driver to select the correct qemu
vhost user socket mode based on the available interface types
reported by the agent.
Change-Id: Iec89eaa597311e086c5f6e8d67308d446b07ac33
Closes-Bug: #1604924
Depends-on: Ia5da5b3ef28d1b23b217adc5196199df47b54ed9
This patch follows up on the Nova work that allows Neutron to pass an
OVS 'bridge_name' in a port's vif_details [1] and the os-vif work that
ensures the OVS bridge passed in as 'bridge_name' (or the config default
of 'br-int') is created [2].
If the port is a trunk's parent port, then bridge_name will be set to a
generated trunk bridge name for vlan-aware VMs. Otherwise, the
bridge_name field will remain empty.
Note: until Nova integrates os-vif [3] and uses a release that contains
the change in [2], the trunk bridge will not actually be created by
Nova/os-vif. It is expected to be integrated for the Newton release.
Until then, this Nova-equivalent patch can be used for testing
purposes [4].
[1] https://review.openstack.org/#/c/260700/
[2] https://review.openstack.org/#/c/330818/
[3] https://review.openstack.org/#/c/269672/
[4] https://review.openstack.org/#/c/332474/
Partially-implements: blueprint vlan-aware-vms
Change-Id: Iad72d163bc406df65866f6d962abcb78596828e7
This adjusts the logic in the OVS mechanism driver to determine
what the ovs_hybrid_plug value should be set to in the VIF details.
Previously it was based purely on the firewall driver configured on
the server side. This prevented a mixed environment where some agents
might be running a native OVS firewall driver while others are still
based on the IPTables hybrid driver.
This patch has the OVS agents report back whether they want hybrid
plugging in their configuration dictionary sent during report_state.
The OVS agent sets this based on an explicit attribute on the firewall
driver requesting OVS hybrid plugging.
To maintain backward compat, if an agent doesn't report this, the old
logic of basing it off of the server-side config is applied.
DocImpact: The server no longer needs to be configured with a firewall
driver for OVS. It will read config from agent state reports.
Closes-Bug: #1560957
Change-Id: Ie554c2d37ce036e7b51818048153b466eee02913
In Liberty and before, the Neutron server never had to be
configured with a firewall driver for the OVS hybrid IPtables filtering
bridge to work. However, in Mitaka, some logic snuck in[1] that made it
so if the driver was not defined, the hybrid plugging would be disabled.
This essentially broke anyone upgrading from Liberty to Mitaka who
was using OVS and did not have the firewall driver configured on the
server.
This patch adjusts the default if the driver is not defined on the
server to automatically set hyrbid plugging to true to preserve the
Liberty behavior.
1. I13e5cda8b5f3a13a60b14d80e54f198f32d7a529
Closes-Bug: #1577584
Change-Id: Ic1e316f2eb4e273e5b9fb045f1822d30af7bda68
This firewall requires OVS 2.5+ version supporting conntrack and kernel
conntrack datapath support (kernel>=4.3). For more information, see
https://github.com/openvswitch/ovs/blob/master/FAQ.md
As part of this new entry points for current reference firewalls were
added.
Configuration:
in openvswitch_agent.ini:
- in securitygroup section set firewall_driver to openvswitch
DocImpact
Closes-bug: #1461000
Co-Authored-By: Miguel Angel Ajo Pelayo <mangelajo@redhat.com>
Co-Authored-By: Amir Sadoughi <amir.sadoughi@rackspace.com>
Change-Id: I13e5cda8b5f3a13a60b14d80e54f198f32d7a529
This commit moves the L2 agents (Linuxbridge and OVS) into the
ML2 directory, while at the same time also moving the ML2 server
bits into toplevel directories. It also moves the configuration
files and unit tests. We also move the l2pop RPC mixin while
here as well.
DocImpact
UpgradeImpact
Partially-Implements: blueprint reference-implementation-split
Partial-Bug: #1468433
Closes-Bug: #1427317
Change-Id: If6feca7b7a6bdd6c3c6feb929fa26fb4b1f72770
Signed-off-by: Kyle Mestery <mestery@mestery.com>
Slawek Kaplonski