The base class "MechanismDriver" now has a property called
"connectivity". This patch overrides the default value in the
in-tree drivers.
The method "_check_drivers_connectivity" now uses this property
that is available in all drivers.
Depends-On: https://review.opendev.org/c/openstack/neutron-lib/+/826501
Closes-Bug: #1959125
bp boot-vm-with-unaddressed-port
Related-Bug: #1821058
Change-Id: I91734835b07d804365b46adfb26e984557107d80
The mechanism driver support VNIC types validation is done now in the
"SimpleAgentMechanismDriverBase" class __init__ method. If a subclass
needs to administratively prohibit any VNIC type supported by default,
"vnic_type_prohibit_list" must be passed to the base class __init__
call.
Related-Bug: #1578989
Change-Id: Ic25a8a7c716b4980ad2542b44519f77c6fdad309
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
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
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
In patch [1] there was added usage of context parameter in method
get_vif_type in openvswitch mech_driver.
This exposed that previously "wrong" context was passed to this method
in _update_segmentation_id() method in ml2 plugin and that caused
raising AttributeError as "Context" object didn't have attribute
'current'.
This patch adds new method "get_supported_vif_type" to mechanism
drivers and this method don't need context to return what vif_types
are supported regarding agent type.
[1] https://review.opendev.org/#/c/658784/
Change-Id: Ic6c738db28208e5009f78bb52598eb3c141f639f
Related-Bug: #1832985
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
Added the ability to change the segmentation ID of a network
with ports bound to OVS agent. The rules, both in the integration
bridge and the physical bridge, to convert the internal VLAN tag
and the external segmentation ID (external VLAN tag) are deleted
and created again with the new value. The traffic from the tenant
networks will be tagged then with the new segmentation ID.
Added get network details agent RPC call to retrieve the information
of the updated network.
Partial-Bug: #1806052
Change-Id: I69f6f3ef717c3ed40218099b1f389afd3d39bd62
Reduces E128 warnings by ~260 to just ~900,
no way we're getting rid of all of them at once (or ever).
Files under neutron/tests still have a ton of E128 warnings.
Change-Id: I9137150ccf129bf443e33428267cd4bc9c323b54
Co-Authored-By: Akihiro Motoki <amotoki@gmail.com>
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
neutron-lib contains a number of the plugin related constants from
neutron.plugins.common.constants. This patch consumes those constants
from neutron-lib and removes them from neutron. In addition the notion
of the dummy plugin service type is moved strictly into the test
package of neutron since it's not a real service plugin.
NeutronLibImpact
Change-Id: I767c626f3fe6159ab3abd6a7ae3cb9893b79bf66
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
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
This will deprecate the notification_driver config setting,
and no config setting will be needed.
Also it lays down the foundation for a more decoupled interaction
with mechanism drivers.
Closes-Bug: #1657379
Related-Bug: #1627749
DocImpact
Change-Id: I2f166a43f0b980ad22617f8a3f7b4cc7f4786c48
- 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
- Changes RULE_TYPE_DSCP_MARK to RULE_TYPE_DSCP_MARKING to conform
with the rules name.
- Added object versioning to qos related objects.
- qos/rule: Throws a QosRuleVersionUnavailable exception when
the QosDscpMarkingRule version is < '1.1'.
- removed test object version incrementation TODO from test_policy.py
- Object versioning can not be used to increment the object version.
Change-Id: I4f10ef3c1cbaa2a868de2b8e3abc4c39eb1f44c7
Partial-Bug: #1468353
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 patch adds the front end and back end implementation of QoS DSCP.
Associated patches that are dependent on this one:
* python-neutronclient: https://review.openstack.org/#/c/254280
* openstack-manuals: https://review.openstack.org/#/c/273638
* API Guide: https://review.openstack.org/#/c/275253
* Heat:
* Spec: https://review.openstack.org/#/c/272173
* QoSDscpMarkingRule resource: https://review.openstack.org/#/c/277567
* Fullstack tests: https://review.openstack.org/#/c/288392/
APIImpact - The API now supports marking traffic egressing from a VM's
dscp field with a valid dscp value.
Co-Authored-By: Nate Johnston <nate_johnston@cable.comcast.com>
Co-Authored-By: Victor Howard <victor.r.howard@gmail.com>
Co-Authored-By: Margaret Frances <margaret_frances@cable.comcast.com>
Co-Authored-By: James Reeves <james.reeves5546@gmail.com>
Co-Authored-By: John Schwarz <jschwarz@redhat.com>
Needed-By: I25ad60c1b9a66e568276a772b8c496987d9f8299
Needed-By: I881b8f5bc9024c20275bc56062de72a1c70c8321
Needed-By: I48ead4b459183db795337ab729830a1b3c0022da
Needed-By: Ib92b172dce48276b90ec75ee5880ddd69040d7c8
Needed-By: I4eb21495e84feea46880caf3360759263e1e8f95
Needed-By: I0ab6a1a0d1430c5791fea1d5b54106c6cc93b937
Partial-Bug: #1468353
Change-Id: Ic3baefe176df05f049a2e06529c58fd65fe6b419
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
Adds the ovs 'config' property which returns the contents of the
single row of the Open_vSwitch table. This gives access to certain
OVS capabilities such as datapath_types and iface_types.
Using this information in concert with the datapath_type config
option, vif details are calculated by the OVS mech driver. If
datapath_type == 'netdev' and OVS on the agent host is capable of
supporting dpdkvhostuser, then it is used.
Authored-By: Terry Wilson <twilson@redhat.com>
Co-Authored-By: Sean Mooney <sean.k.mooney@intel.com>
Closes-Bug: #1506127
Change-Id: I5047f1d1276e2f52ff02a0cba136e222779d059c
Every plugin that supports some of QoS rules will define a property
called supported_qos_rule_types of list type.
For ml2, determine supported qos rule types as a subset of rule types
supported by all drivers. (In the future, we may expand the list to
include all types supported by at least one of enabled drivers. This
would require synchronized work with nova scheduler though.)
For ml2, tests are limited, and should be expanded to check that common
subset of qos rules is calculated properly when intersection != the list
of each plugins. For now, it's enough since we don't have more than one
rule type planned for Liberty.
Added API test for the resource.
Partially-Implements: blueprint ml2-qos
Co-Authored-By: Irena Berezovsky <irenab.dev@gmail.com>
Co-Authored-By: John Schwarz <jschwarz@redhat.com>
Change-Id: I0d18ae256877a129e203110003fcadd1d63590b4
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