Running with a stricter .pylintrc generates a lot of
C0330 warnings (hanging/continued indentation). Fix
some remaining ones in miscellaneous directories.
Also cleanup any remaining code that I missed in this
series, or has changed since I started.
Trivialfix
Change-Id: I17b4779020a7bfb369c3e721ab6638cd4a6ab50c
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
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
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
Add support in SR-IOV mechanism driver for VNIC type
"accelerator-direct".
This VNIC type refers to any device that supports hardware
acceleration of any kind and is provided by Cyborg [1].
NOTE: "accelerator-direct-physical" is not supported yet.
[1]https://wiki.openstack.org/wiki/Cyborg
Change-Id: I529e6a2a445a140dca7686976efeefcd13d333f0
Closes-Bug: #1909100
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
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
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: Iad9e2e966df53b4164d2a56a93215c69825b5241
Partial-Bug: #1578989
See-Also: https://review.openstack.org/502306 (nova spec)
See-Also: https://review.openstack.org/508149 (neutron spec)
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
Since Pike log messages should not be translated.
This patch removes calls to i18n _LC, _LI, _LE, _LW from
logging logic throughout the code. Translators definition
from neutron._i18n is removed as well.
This patch also removes log translation verification from
ignore directive in tox.ini.
Change-Id: If9aa76fcf121c0e61a7c08088006c5873faee56e
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
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
While referencing VIF types during the QoS plugin drivers refactor
I noticed that SR-IOV had the VIF type constants defined in the
mech_driver itself, instead of the portbindings extension.
I wanted to make all the VIF type constants available from a single
place instead of scattered.
Change-Id: Iabb7e5e953c4509c39b2029839752b88af87387b
The SR-IOV option supported_pci_vendor_devs has been deprecated in Newton
and This change removes it from Ocata.
Change-Id: I42dadfd0b62730ca2d34d37cb63f19f6fec75567
This patch adds SR-IOV agent driver, which uses eswitch manager, to set
VF min_tx_rate parameter. This parameter defines the guaranteed minimum
bandwidth for egress traffic.
DocImpact
Partial-Bug: #1560963
Change-Id: Iefe5e698e99d186202d6ef170f84e93bfbba46dd
As the SR-IOV mechanism driver does not impact VLAN transparency
support, this patch overrides the check_vlan_transparency method
from the MechanismDriver base class and returns 'True'. In this
way, inclusion of the SR-IOV mechanism driver in the list of
configured mechanism_drivers does not prevent the creation of
VLAN transparent networks.
Change-Id: Ie35ce63102e59891d040c01c847936f918e0d6ea
Closes-Bug: #1616480
Deprecate the supported_pci_vendor_devs option in order to reduce
complexity for configuring SR-IOV. Currently, neutron validates the pci
vendor and product id. However this check is already done by the
nova-scheduler when it selects a suitable hypervisor. More precisely,
the compute node validates this through the pci_passthrough_whitelist
option in nova.conf. Therefore this check in neutron is redundant.
This patch deprecates the supported_pci_vendor_devs in Newton release
and updates the supported_pci_vendor_devs default to None.
In case of None value the SR-IOV mechanism driver won't do
any pci vendor validation. In case this option is set
the SR-IOV mechanism driver will do the validaiton as it was
before.
DocImpact
Closes-bug: #1611302
Change-Id: Id5e2cef44da871965583abbae3e1140fd4f5786c
Since commit 83c9578fcc was merged, the
SR-IOV mechanism driver requires an agent in the compute nodes. This
change makes the SR-IOV mechanism driver to inherit from
SimpleAgentMechanismDriverBase, like all the other agent based ML2
drivers
Change-Id: Icffc097a42dd71546b97bb7b43edd1e205c9dd15
Closes-Bug: #1578274
Currently neutron DCHP scheduler assumes that that every server running
a dhcp-agent can reach every network. Typically the scheduler can
wrongly schedule a vlan network on a dhcp-agent that has no reachability
to the network it's supposed to serve (ex: network's physical_network
not supported).
Typically such usecase can append if:
* physical_networks are dedicated to a specific service and we don't
want to mix dnsmasqs related to different services (for
isolation/configuration purpose),
* physical_networks are dedicated to a specific rack (see example
diagram http://i.imgur.com/NTBxRxk.png), the rack interconnection can
be handled outside of neutron or inside when routed-networks will be
supported.
This change makes the DHCP scheduler network reachability aware by
querying plugin's filter_hosts_with_network_access method.
This change provides an implementation for ML2 plugin delegating host
filtering to its mechanism drivers: it aggregates the filtering done by
each mechanism or disables filtering if any mechanism doesn't overload
default mechanism implementation[1] (for backward compatibility with
out-of-tree mechanisms). Every in-tree mechanism overloads the default
implementation: OVS/LB/SRIOV mechanisms use their agent mapping to filter
hosts, l2pop/test/logger ones return empty set (they provide to "L2
capability").
This change provides a default implementation[2] for other plugins
filtering nothing (for backward compatibility), they can overload it to
provide their own implementation.
Such host filtering has some limitations if a dhcp-agent is on a host
handled by multiple l2 mechanisms with one mechanism claiming network
reachability but not the one handling dhcp-agent ports. Indeed the
host is able to reach the network but not dhcp-agent ports! Such
limitation will be handled in a follow-up change using host+vif_type
filtering.
[1] neutron.plugin.ml2.driver_api.MechanismDriver.\
filter_hosts_with_network_access
[2] neutron.db.agents_db.AgentDbMixin.filter_hosts_with_network_access
Closes-Bug: #1478100
Co-Authored-By: Cedric Brandily <zzelle@gmail.com>
Change-Id: I0501d47404c8adbec4bccb84ac5980e045da68b3
We need to tell Nova to use a specific VIF type for full PF passthrough
(this is the recently added VNIC_DIRECT_PHYSICAL vnic type).
Make sure that when binding ports with this vnic type, we set the
appropriate vif type for Nova to be able to provision those ports
correctly.
Nova change that adds a vif driver for this vif type:
https://review.openstack.org/#/c/262583/
DocImpact: Exposes a new vif type for PF passtrhough vnic type
Change-Id: I895dab98e5e5a9369771539e51ba5c500bfe0045
Related-blueprint: sriov-pf-passthrough-neutron-port
This change adds a new VNIC type to distinguish between virtual and
physical functions in SR-IOV.
The new VNIC type 'direct-physical' deviates from the behavior of
'direct' VNICs for virtual functions. While neutron tracks the resource
as a port, it does not currently perform any management functions.
Future changes may extend the segment mapping functionality that is
currently based on agent configuration to include direct types.
However, the direct-physical VNICs will not have functional parity with
the other SR-IOV VNIC types in that quality of service and port security
functionality is not available.
APIImpact
DocImpact: Add description for new 'direct-physical' VNIC type.
Closes-Bug: #1500993
Change-Id: If1ab969c2002c649a3d51635ca2765c262e2d37f
- This does NOT break other projects that rely on neutron.i18n,
as this change includes a debtcollector shim to maintain those
older entry points, until they can migrate.
- Also updates _i18n.py to the latest pattern defined by oslo_i18n
- Guidance and template are from the reference:
http://docs.openstack.org/developer/oslo.i18n/usage.html
Partially-Closes-Bug: #1519493
Change-Id: I1aa3a5fd837d9156da4643a367013c869ed8bf9d
This adds a new tox environment, genconfig, which generates sample
neutron core configuration file using oslo-config-generator.
Updates to some configuration option help messages to reflect useful
details that were missing in the code but were present in config files.
It also adds details to devref on how to update config files.
Partially-Implements: blueprint autogen-neutron-conf-file
DocImpact
Change-Id: I1c6dc4e7d479f1b7c755597caded24a0f018c712
Closes-bug: #1199963
Co-Authored-By: Louis Taylor <louis@kragniz.eu>
The SR-IOV option agent_required has been deprecated in Liberty.
This change removes it and from now agents are mandatory for SR-IOV
mechanism in order to support extended features: QoS, port security.
DocImpact
Closes-Bug: #1508182
Related-Bug: #1488807
Change-Id: I4e6497da6b287531a211084a5208028c84112a83
When SR-IOV introduce in Juno Agent supported only link state change
Some Intel cards don't support setting link state, so to
resolve it the SR-IOV mech driver supports agent and agent less mode.
From Liberty the SR-IOV agent brings more functionality like
qos and port security so we want to make the agent mandatory.
(of course I already talked with Intel Guys to get their approval)
This patch deprecates the agent_required in Liberty
and updates the agent_required default to be True.
DocImpact
Closes-bug: #1488807
Change-Id: I8799425c2825415ef05bec909e6b4085ffc1e3c5
VIF_TYPE_* constants[1] defines all vif types BUT vendor ones are only
used by in-tree/out-of-tree vendor code. This changes moves in-tree
VIF_TYPE_* constants[2] to vendor modules to ensure they will be removed
from neutron code on decomposition.
[1] in neutron.extensions.portbindings
[2] VIF_TYPE_HYPERV/IB_HOSTDEV/HW_WEB/VROUTER
Change-Id: Iee73426221d693689ba24d2ce2660bb7351f02fc
Partial-Bug: #1486279
This patch adds SR-IOV agent driver which uses eswitch manager to set VF
rate limit. It also updates the agent to call port_delete api of the
extension manager to cleanup when port is deleted.
Partially-Implements: blueprint ml2-sriov-qos-with-bwlimiting
Change-Id: I364fc8158e502d4dcc3510d6157f12969961a11d
In preparation for decomposing the built-in reference implementation,
this commits consolidates the sriov agent and driver code into a
coherent place for it's life in the new repository. I've also given
the unit tests a new home.
DocImpact
UpgradeImpact
Partially-Implements: blueprint reference-implementation-split
Partial-Bug: #1468433
Closes-Bug: #1427317
Change-Id: Ic8b5215de76e191030228bc28773cd6535e889d8
Signed-off-by: Kyle Mestery <mestery@mestery.com>
Brian Haley
