Added support for filtering the QoS rule type list command.
Two new filter flags are added:
- all_supported: if True, the listing call will print all QoS rule
types supported by at least one loaded mechanism driver.
- all_rules: if True, the listing call will print all QoS rule types
supported by the Neutron server.
Both filter flags are exclusive and not required.
Depends-On: https://review.opendev.org/c/openstack/neutron-lib/+/827533
Closes-Bug: #1959749
Change-Id: I41eaab177e121316c3daec34b309c266e2f81979
Traditionally it has been the CMSs, in OpenStacks case Nova's,
responsibility to create Virtual Interfaces (VIFs) as part of
instance life cycle, and subsequently manage plug/unplug operations
on the Open vSwitch integration bridge.
With the advent of SmartNIC DPUs which are connected to multiple
distinct CPUs we can have a topology where the instance runs on one
host and Open vSwitch and OVN runs on a different host, the
SmartNIC DPU control plane CPU.
One of the main use cases for having this topology is security
where we treat the hypervisor host as untrusted and prohibit
direct communication between the hypervisor host and the SmartNIC
DPU control plane host. In addition to that control facilities
such as switchdev devices are only visible from the SmartNIC DPU
control plane CPUs.
Adds support for binding ports of type VNIC_REMOTE_MANAGED by
looking up chassis based on serial number that Nova provides in
the binding_profile.
Information required by the OVN controller to successfully look up
and plug representor port is provided as options on the LSP as
defined by the representor plug provider documentation [0][1].
0: https://docs.ovn.org/en/stable/topics/vif-plug-providers/vif-plug-providers.html
1: https://github.com/ovn-org/ovn-vif/blob/main/Documentation/topics/vif-plug-providers/vif-plug-representor.rst
Partial-Bug: #1932154
Depends-On: I496db96ea40da3bee5b81bcee1edc79e1f46b541
Depends-On: I83a128a260acdd8bf78fede566af6881b8b82a9c
Change-Id: Icc6c2d0f7f8f5cc94997db6244175a8e8884789f
Introduce a new API extension to enable GET, PUT and DELETE
operations on QoS minimum packet rate rule without specifying
policy ID.
Partial-Bug: #1922237
See-Also: https://review.opendev.org/785236
Change-Id: Ia083b5ac98c9e18ddbcdd2e0fc46f2f8432a628c
Now "L3AgentExtensionsManager" lists loaded extension, checking if
they inherit from "neutron_lib.agent.l3_extension.L3AgentExtension".
If any extension does not, the L3 agent raises an exception and exits.
Closes-Bug: #1951569
Change-Id: I3ce4858cef9b3a3d7eab005dd1ad2bb3b5ef6ef3
Floating IP now have information of the QoS policy of the external
network. The OVN QoS extension will use this network QoS policy if
there is no floating IP QoS policy.
Partial-Bug: #1950454
Change-Id: I380a130d97e8bfe54caa5f3a129877507d1ce2a6
Added a check for OVN SB schema, looking for "virtual_parent" in
"Port_Binding" table (added in OVN SB schema 2.5).
This patch removes the code to support OVN without virtual ports.
It is assumed that "virtual_parent" field is present in "Port_Binding"
table.
Closes-Bug: #1949496
Change-Id: I3d01f58dca570537b5e754b331ca4809a7161ae2
The [agent] veth_mtu parameter has had unused since the [ovs]
use_veth_interconnection parameter was removed by [1] during Wallaby.
[1] https://review.opendev.org/c/openstack/neutron/+/759947
This change formally deprecate the parameter so that we can remove it
in a next cycle.
Change-Id: Ib85959fbc06928a49df7ea104eae3aca3f04e091
Closes-Bug: #1957180
Not Neutron nor other active projects use "PortBindingMixin" class or
the table "portbindingports" anymore.
Closes-Bug: #1956980
Change-Id: I34424a271f6c66cd99852c6109a96a4dcf374913
Added a check for OVN NB schema, looking for "options" field in "NAT"
table (added in OVN NB schema 5.17).
This patch removes the code to support OVN without stateless NAT rules.
It is assumed that "options" field in "NAT" table is always present.
Closes-Bug: #1949494
Change-Id: Ib3b6dd68009ab635627168b11626d7e7c548ee2f
Same as in other ML2 plugins (OVS, Linux Bridge), OVN mechanism driver
should allow only one physical network per bridge. The rule "one
network, one bridge" should be present in OVN too.
By allowing only one physical network per bridge, Neutron prevents
having two networks with subnets with the same CIDR in the same bridge.
Currently is possible and this CIDR clash is not prevented (shouldn't be
by the API). This architectural limitation prevents this situation.
This limitation is already present in deployment tools as TripleO.
Closes-Bug: #1956476
Change-Id: I74a2ca9a344a93219deb94d60247478ee3200659
When ovn/dns_servers consist of IPv6 dns nameservers,
it was getting added to IPv4 dhcp options also, and due to
this an invalid nameserver(last 4 octets of an IPv6 address)
is set in the instances.
This patch filters IPv4/IPv6 dns nameservers and set
dhcpv4/dhcpv6 options accordingly.
Also when dns_nameservers are not set for IPv6 subnets,
get those from ovn/dns_servers config or system nameservers
just like it's done with the IPv4 subnets. Updated
get_system_dns_resolvers to pick both IPv4/IPv6 valid
ips, this also requires bump of oslo.utils minimum version
to 4.8.0 to use strict option for IPv4[1].
Additionally fix some unit tests which were setting IPv4 dns
nameservers on the IPv6 subnets, this is not allowed with api.
[1] https://github.com/openstack/oslo.utils/commit/3288539
Closes-Bug: #1951816
Change-Id: I9f914e721201072e43a8c6c266ed97ca85fcc13d
It was added temporary to have compatybility with 3rd party code
which uses Neutron interface driver but it was said that since
"W" release that old, deprecated way of calling "plug_new" method
will be removed. Now we are far after "W" release so it's time to
do some cleaning there.
Related-Bug: #1879307
Change-Id: I03214079f752c7efe6611f2e928f32652fe681bc
Today the sriov qos service plugin blindly blocks creating ports
with minimum bandwidth qos and with direct_physical vnic_type. This was
originally added when only dataplane enforcement was the scope of the
qos service plugin. However in the last many releases we created
placement enforcement for this qos rule regardless of the vnic_type.
So now blindly blocking the port creation is now preventing using the
placement enforcement for this rule for direct_physical ports.
This patch removes this limitation by marking minimum bandwidth as
supported rule for the sriov qos service plugin. The limitation that
data plane enforcement is not supported for this rule remains. The agent
will not even try to apply any kind of rules to these ports as port
binding is not forwarded for the sriov agent at all.
The documentation is extended to explain that placement enforcement now
works while data plane enforcement still not supported.
This is somewhat similar to the case when the support for egress
direction is added to the minimum bandwidth rule, while the sriov data
plane enforcement was not (could not) been implemented for this
direction in the sriov agent. Today the sriov agent simply ignores the
egress direction rules in the minimum bandwidth qos rule during applying
the data plane enforcement.
Closes-Bug: #1949877
Change-Id: I20ad32eac414ff90b551bff940d92cbcfa848101
When I writing 'ndp_proxy' service plugin, I found I couldn't get enough
informations about router from the callback system (Such as: the origin
request body of user send). So, for write service plugin that related
router plugin more concisely I commit this patch.
This patch proposal two changes about router callback publish events:
1. Add 'request_body' parameter to some event's payload
2. add 'BEFORE_UPDATE' event for router gateway
Related-bug: #1877301
Change-Id: I5f6a4e6f0b7c5feb794ddb7efbd07d01bad91af8
Neutron allows deleting the only IP of a router port but
the OVN NB DB doesn't, since it expects that the
network value of a port is greater than 0. This should
not be possible since it causes that the DB are not
perfectly sync.
It is needed to check BEFORE_UPDATE if the port
that will be updated is of type router owned and
if it will have an IP after the update. If not
an error needs to be raised.
Closes-Bug: #1948457
Change-Id: I206c31201470f178efdde8839622be7900c6ae3e
This patch does *not* implement dataplane enforcement.
QoS minimum packet rate rule is enabled in OVS backend driver and
create/delete/update empty methods are added to enable placement
enforcement.
Partial-Bug: #1922237
See-Also: https://review.opendev.org/785236
Change-Id: Ie283ad3a4ec433c88ac23f798908cd143159394b
With the introduction of port-resource-request-groups extension,
format of binding-profile.allocation has changed. Since the DB,
may contain port bindings that were created before the introduction
of the new format, it's necessary to perform upgrade check and
sanitize those rows that are still using an older format.
Partial-Bug: #1922237
See-Also: https://review.opendev.org/785236
Change-Id: I95e9e1bc553ac499d75c9280e45dfea61d135279
Config option allow_overlapping_ips is deprecated to removal now and
will be removed in the Z cycle.
Default value for that option is now set to True as this is supported by
IPAM module in Neutron.
Related-Bug: #1942294
Change-Id: I17bf5e4483025e9cc4ee04dd3e7c925f7bddc3db
The OVN driver needs to announce all DNS extensions as supported,
otherwise the neutron server will reject them.
Closes-Bug: 1947127
Signed-off-by: Dr. Jens Harbott <harbott@osism.tech>
Change-Id: Ic269902ef7a16893c4ea624b04347d04db4f52d9
Added a check for OVN NB schema, looking for "Port_Group" table
(added in OVN NB schema 5.11).
This patch removes the code to support OVN without "Port_Group"
table. It is assumed that this table is always present.
Closes-Bug: #1946023
Change-Id: If193ff5bc6e1421f4fa9db3779872a82a36c8b69
Report the packet processing capacity on the Neutron agent resource
provider to Placement as the new 'NET_PACKET_RATE_KILOPACKET_PER_SEC'
or 'NET_PACKET_RATE_[E|I]GR_KILOPACKET_PER_SEC' resource inventory.
This is similar to how the bandwidth resource is reported today.
Partial-Bug: #1922237
See-Also: https://review.opendev.org/785236
Change-Id: I8deefbeed4b4b51dd20062df62c8891fee3ebf9d
Add the shared field to security group API responses and support
using shared as a query filter.
A follow-up patch will remove the temporary api def once it is merged
and released in neutron-lib.
Related-Bug: #1942615
Depends-On: https://review.opendev.org/c/openstack/neutron-lib/+/812617
Change-Id: Ic04be8f0b7097c8aed19365f06089aa7af333eb9
When two segments are concurrently created this could have resulted in
both threads creating a segment, thus resulting in two segments with
different segmentation ids. To prevent this we now introduce a new
unique constraint onto the networksegments table, which requires
(network_id, network_type, physical_network) to be unique, which allows
only a single segment with a single segmentation id to exist per
combination of these three values.
With the constraint in place a DB error will be thrown, which will cause
allocate_dynamic_segment() to be executed again and this time it will
find the already existing segment. To make sure that no additional DB
objects are created when segment creation failed we need to put all of
the allocation code into a DB transaction.
Change-Id: I407ae88d69ed971bf8d9a9b79120366f33bb56fd
Closes-Bug: #1791233
The goal of [1] is to, in case of failing when removing the quota
reservation, continue the operation. Any expired reservation will
be removed automatically in any driver.
If the DB transaction fails, it should affect only to the reservation
trying to be deleted. This is why this patch isolates the
"remove_reservation" method and guarantees it is called outside an
active DB session. That guarantees, in case of failure, no other DB
operation will be affected.
This patch also partially reverts [2] but still checks the security
group rule quota when a new security group is created. Instead of
creating and releasing a quota reservation for the security group
rules created, now only the available quota limit is checked before
creating them. That won't prevent another operation to create security
group rules in parallel, exceeding the available quota. However, this
is not even guaranteed with the current quota driver.
[1]https://review.opendev.org/c/openstack/neutron/+/805031
[2]https://review.opendev.org/c/openstack/neutron/+/701565
Closes-Bug: #1943714
Change-Id: Id73368576a948f78a043d7cf0be16661a65626a9
OVS agent configuration is extended to support new configuration
options:
- 'resource_provider_packet_processing_without_direction'
- 'resource_provider_packet_processing_with_direction'
- 'resource_provider_packet_processing_inventory_defaults'
OVS agent RPC hearthbeat now reports this information to neutron
server in 'configuration' field .
Example config:
ml2_conf.ini:
[ovs]
resource_provider_packet_processing_with_direction = :1000:1000
Partial-Bug: #1922237
See-Also: https://review.opendev.org/785236
Change-Id: Ief554bc445dfd93ea6995bb42b4d010674c7a091
This patch implements support for CRUD operations for QoS minimum
packet rate, for example:
DELETE /qos/policies/$POLICY_ID/minimum_packet_rate_rules/$RULE_ID
Placement or dataplane enforcement is not implemented yet.
Partial-Bug: #1922237
See-Also: https://review.opendev.org/785236
Change-Id: Ie994bdab62bab33737f25287e568519c782dea9a
Using stateless NAT in OVN should always be a better choice for FIPs
because it allows to avoid hitting conntrack, potentially improving
NAT performance, esp. where hardware offload for the openflow rules is
involved.
The only limitation for using stateless NAT in OVN is that it requires
1:1 IP mapping; which is always the case for FIPs. This is why this
patch unconditionally switches to stateless for all FIPs.
Before setting stateless key to NAT's options, check that 'options'
are supported. (Support was added in OVN 20.03 as part of stateless
NAT implementation.) If an older OVN version is used, nothing changes.
The patch also adds a runtime migration rule for neutron-server to
transform all existing stateful fips to stateless.
Change-Id: I312a950131d62d93fb4bc121bc5e60febb8d35ee