This patch adds support for QoS minimum bandwidth rules in tunnelled
networks. Now the ML2/OVS and ML2/OVN mechanism drivers can represent
in the Placement API the available bandwidth of the tunnelled networks
in each compute host.
Both mechanism drivers represent the compute VTEP (VXLAN) or TEP
(Geneve) interface as an IP address. This new resource provider
(by default called "rp_tunnelled") represents the available bandwidth
of this interface. Any new port created in a compute node that belongs
to a tunnelled network, will request to the Placement API the
corresponding bandwidth from the resource provider inventory.
This patch does not provide backend enforcement support for minimum
bandwidth rules.
RFE spec: https://review.opendev.org/c/openstack/neutron-specs/+/860859
What is missing and will be added in next patches:
* Tempest tests, that will be pushed to the corresponding repository.
Depends-On: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/863880
Partial-Bug: #1991965
Related-Bug: #1578989
Change-Id: I3bfc2c0f9566bcc6861ca91339e32257ea92c7e9
Issue[1] workaround: A wrapper class which determines if socket module
was eventlet patched and request std lib socket module instead.
Also adding LOG.warning into the exception block so we dont miss
issues like this in the future.
Closes-Bug: #1980967
Related-Bug: #1926693
[1]https://github.com/eventlet/eventlet/issues/764
Change-Id: I41c4cbc1aaea95f7808e6c6dca47ecd0402351c9
This change ensures that neutron relies on the same logic as libvirt
to generate hypervisor hostname, to fix imcompatible hostname format
used in Nova and Neutron for resource provider name in some
configuration pattens like the one generated by TripleO.
Closes-Bug: #1926693
Change-Id: Iea2533f4c52935b4ecda9ec22fb619c131febfa1
Currently neutron uses socket.gethostname() to determine hypervisor
names, but this implementation is not fully compatible with libvirt
driver which uses canonical name for hypervisor name.
This incompatibility causes an issue with root resource provider
detection if a deployment uses FQDNs as canonicanl names.
This change introduces the resource_provider_default_hypervisor option,
so that users can override the hypervisor name by the single option(*1)
instead of setting two list options(*2). This is especially useful if
the deployment has multiple bridges or interfaces.
(*1)
[OVS]
resource_provider_bandwidths=br-data1:1024:1024,br-data2:1024:1024,\
br-data3:1024,1024,br-data4,1024:1024
resource_provider_default_hypervisor=compute0.mydomain
(*2)
[OVS]
resource_provider_bandwidths=br-data1:1024:1024,br-data2:1024:1024,\
br-data3:1024,1024,br-data4,1024:1024
resource_provider_hypervisors=br-data1:compute0.mydomain,br-data2:\
compute0.mydomain,br-data3:compute0.mydomain,br-data4:compute0.mydomain
Related-Bug: #1926693
Change-Id: I692219200535df3af1265248e88c96947e4d8f9d
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
Previously we assumed that we can look up the resource provider (created
by nova) to be used as the parent of the agent and physical NIC resource
provider tree by the name set in the config option DEFAULT.host. This
assumption was wrong.
While nova-compute's DEFAULT.host and neutron-agent's DEFAULT.host
must match for port binding to work, the root resource provider created
by nova does not belong to the compute host (where nova-compute runs)
but it belongs to the compute nodes (i.e. hypervisors). Actually there
may be multiple compute nodes managed by a single nova-compute (think
of ironic). Plus the value of DEFAULT.host and the compute node's ID
may be different even when nova-compute manages a hypervisor on the
same host because of various deployment considerations. For example
when tripleo does not manage the undercloud (so a libvirt hypervisor
returns the plain hostname), but the same tripleo enforces it's host
naming conventions in nova's and neutron's DEFAULT.host settings.
This change enables neutron to use the hypervisor name to locate the
root of the resource provider tree.
We introduce a new configuration option for
(1) ovs-agent: resource_provider_hypervisors, for example:
[ovs]
bridge_mappings = physnet0:br-physnet0,...
resource_provider_bandwidths = br-physnet0:10000000:10000000,...
resource_provider_hypervisors = br-physnet0:hypervisor0,...
(2) sriov-agent: resource_provider_hypervisors, for example:
[sriov_nic]
bridge_mappings = physnet1:ens5,...
resource_provider_bandwidths = ens5:10000000:10000000,...
resource_provider_hypervisors = ens5:hypervisor1,...
For both agents 'resource_provider_hypervisors' values default to
socket.gethostname() for each key in resource_provider_bandwidths.
We try to not block later developments in which one neutron
agent may manage devices on multiple hosts. That's why we allow
the each physdev to be associated with a different hypervisor.
But here we do not try to solve the problem that the natural physdev
identifiers may not be unique accross multiple hosts. We leave solving
this problem to whoever wants to implement an agent handling devices of
multiple hosts.
(3) We extend report_state message's configurations field alike:
{
'bridge_mappings': {'physnet0': 'br-physnet0'},
'resource_provider_bandwidths': {
'br-physnet0': {'egress': 10000000, 'ingress': 10000000}},
'resource_provider_hypervisors': {'br-physnet0': 'hypervisor0'},
...
}
(4) In neutron-server we use
report_state.configurations.resource_provider_hypervisors.PHYSDEV
when selecting parent resource provider for agent and physdev
RP-tree. When not available in the message we fall back to using
report_state.host as before.
Since we only changed the free-format configurations field of the
report_state message rpc version is not bumped and we expect this
change to be backported to stein and train.
Change-Id: I9b08a3a9c20b702b745b41d4885fb5120fd665ce
Closes-Bug: #1853840
Refactoring neutron agent linux and ovsdb config opts
to be in neutron/conf/agent so that all the config options
reside in a centralized location. This simplifies the
process of looking up the config opts and provides an easy
way to import.
NeutronLibImpact
Change-Id: Ib1e0e63dec2985c417412d1ecc68e2a74ef87182
Partial-Bug: #1563069
Refactoring Neutron configuration options for agent common config to be
in neutron/conf/agent/common. This will allow centralization of all
configuration options and provide an easy way to import.
Partial-Bug: #1563069
Change-Id: Iebac0cdd3bcfd0135349128921b7ad7a1a939ab8
Needed-By: Ib676003bbe909b5a9013a3178b12dbe291d936af
Now it lives in networking-midonet repository.
Closes-Bug: #1510826
Depends-On: I0a4d19ddeddfde2319dcbe24665a24d371625b10
Related-blueprint: core-vendor-decomposition
Change-Id: Ifd18ee1703541d04f1a4717a8b0b8e6dc61a2f4e
Changed the interface_driver configure for agents from class
imports to stevedor aliases. The loading method needed to be
updated to load as a DriverManager. Backward compatability
for configuration as class import.
DocImpact
Change-Id: Ic349691989484286cd7c60eaf3ad1454c5852d1f
Closes-Bug: #1504536
IPv6 protocol requires a minimum MTU of 1280 bytes on the interface
to configure an IPv6 address to the interface. This patch logs an
appropriate error message and exits the agent if ipv6 is enabled and
network_device_mtu is less than the minimum value.
DocImpact
Closes-Bug: #1475015
Change-Id: I13666de4e6f5f6775ad26342e513c3c17a003b8e
oslo_utils raise ImportError if import fails. We should propagate other
failures to callers. Otherwise we may hide issues.
Also report exact failure from import_object in case L3 agent fails to
import interface_driver.
As part of the job, consolidated code to load interface driver into
common function.
Also, stopped checking for specific log messages in dhcp and l3 agent
unit tests: it's too fragile and actually not something we need a unit
test for.
Not to introduce more work for people who handle py3 porting effort,
added the unit test into the list of those that are executed for py34
job until the whole suite is ready for python3.
Change-Id: I10cdb8414c9fb4ad5cfd3f3b2630811f50ffb0c7
Rodolfo Alonso Hernandez