In ML2/OVN, during a live-migration process, it could
happend that the port provisioning event is received before
the port binding has been updated. That means the port has
been created in the destination host and the event received
(this event will remove any pending provisioning block). But
the Nova port binding request has not arrived yet, updating
the port binding registers. Because the port is considered
"not bound" (yet), the port provisioning doesn't set the port
status to ACTIVE.
This patch creates an active wait during the port provisioning
event method. If the port binding is still "unbound", the method
retries the port retrieval several times, giving some time to the
port binding request from Nova to arrive.
Closes-Bug: #1988199
Change-Id: I50091c84e67c172c94ce9140f23235421599185c
In some specific use case, the cloud operator expects the source port
of a packet to stay the same across all masquerading layer up to the
destination host. With the implementation of the random-fully code,
this behavior was changed as source_port is always rewritten no matter
which type of architecture / network CIDRs is being used in the backend.
This setting allows a user to fallback to the original behavior of the
masquerading process which is to keep the source_port consistent across
all layers. The initial random-fully fix prevents packet drops when
duplicate tuples are generated from two different namespace when the
source_ip:source_port goes toward the same destination so enabling this
setting would allow this issue to show again. Perhaps a right approach
here would be to fix this "racey" situation in the kernel by perhaps
using the mac address as a seed to the tuple ...
Change-Id: Idfe5e51007b9a3eaa48779cd01edbca2f586eee5
Closes-bug: #1987396
A new script to remove the duplicated port bindings was added. This
script will list all ``ml2_port_bindings`` records in the database,
finding those ones with the same port ID. Then the script removes
those ones with status=INACTIVE. This script is useful to remove
those leftovers that remain in the database after a failed live
migration.
"dry_run" mode is possible if selected in "[cli_script] dry_run"
boolean config option. The duplicated port bindings are printed in
the shell but not deleted.
Related-Bug: #1979072
Change-Id: I0de5fbb70eb852f82bd311616557985d1ce89bbf
This patch adds support for QoS egress minimum bandwidth rules in
ML2/OVN. The enforcement is done in the network backend.
Since [1], in v22.06.0, OVN is capable of guarantee a minimal
bandwidth for a logical switch port. The enforcement of this rule
is done in the physical bridge interface.
[1]dbf12e5fe1
Closes-Bug: #1982951
Change-Id: Ia3831b18463c29f676c253edb64419667b5f2c0b
The ML2/OVN driver wasn't handling updates to the segmentation ID for a
given network. This patch fixes this problem.
This patch extends the _update_segmentation_id() method to check on
drivers which does not inherits from AgentMechanismDriverBase, which
is the case of OVN (which inherits from MechanismDriver). A new method
is now called for those drivers to get a list of supported VIF types,
called get_supported_vif_types().
Closes-Bug: #1944708
Change-Id: Ibe08bfbc2efc55b9d628cdd0605941b7486186b6
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
During the Zed PTG it was decided to handle unsupported features in
Neutron as experimental. See section titled "When we say something is
not supported?", day 2 in [1]. The agreement was:
"We keep existing jobs for linuxbridge driver for example, but when the
tests start to fail we skip them and finally we stop the job also.
To make it clear for operators we add warning logs highlighting that the
given feature/driver is experimental, and introduce cfg option to enable
such features explicitly."
This commit implements this agreement, initially with Linuxbridge
Depends-On: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/845646
[1] https://lists.openstack.org/pipermail/openstack-discuss/2022-April/028164.html
Change-Id: Ib18efa3f472736b58c8967847b1061da0e3897d7
I forgot to write a release note when pushing change 834162 [1].
It may be an important change for operators so it's good to have a
release note about that.
[1] https://review.opendev.org/c/openstack/neutron/+/834162
Related-Bug: #1952907
Change-Id: Ie707f461af11357d6eaa004bc98c7eb09a62202f
This is an effective revert of:
I312a950131d62d93fb4bc121bc5e60febb8d35ee
"ovn: use stateless NAT rules for FIPs".
The performance benefits promised by the "reverted" patch never
materialized. On the contrary, the discussion in [1] revealed that the
switch to stateless=true made it impossible to fully hw offload nat
rules, while it's possible with stateless=false. Specifically, see this
comment [2].
Since at this point it's unclear if keeping stateless=true as an option
is beneficial for any case, even when w/o hw offload, and to avoid
complexity of introducing a config option for unclear benefit, this
patch reverts the effects of the original patch, switching all
dnat_and_snat objects to implicit stateless=false state.
This patch cannot be a clean revert because of the need for db
migration.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2004995
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2004995#c18
Change-Id: I9e6e05b7a4f36383a44bd80f07d25052b17bdfa0
Create multiple ndp proxies with same ip address within one router
is invalid. The related database constraint was missed in previous
patchsets. The patch add some codes fixed this error.
Additionally, Fixed two typo errors.
Related-Bug: #1877301
Change-Id: Iab24ad78a3d4d9b0ee584cf0986328c9ae2bd16a
This patch adds support for deploying baremetal nodes with OVN's
built-in DHCP server for IPv4.
Since Neutron API's for setting DHCP options is mostly a pass-thru,
Ironic uses a dnsmasq syntax for setting the baremetal options [0].
Since this syntax is unlikely to change and it's only a tiny subset of
what dnsmasq can offer this patch does translate that syntax used by
Ironic and convert it to OVN's equivalent options. In this way we do not
need to re-design Neutron's DHCP options API nor change Ironic to use it
with ML2/OVN.
This option also adds a new configuration option called
"disable_ovn_dhcp_for_baremetal_ports". PXE booting nodes can be very
sensitive and operators may prefer to use a fully-fledged DHCP server to
do it (even Ironic makes DHCP pluggable). So if operators wish to
disable OVN's built-in DHCP server for baremetal provisioning they can
do so by setting this new option to True. It defaults to False.
This change has been tested with real hardware and it does work. That
said, we found a problem in core OVN itself [1] while testing it that
can affect PXE from reaching the TFTP server, we already communicated
this with the core OVN folks and we hope it can be fixed soon. The
change in core OVN should not affect the Neutron change tho.
Not that the "server-ip-address" DHCP Option now points to the
"next_server" option in OVN instead of the "tftp_server_address". The
previous behavior was wrong, the "server-ip-address" should set the
"siaddr" in the DHCP header and this has been introduced in OVN [2] as
an option called "next_server".
[0]
49113385e8/ironic/common/pxe_utils.py (L523-L538)
[1]
https://mail.openvswitch.org/pipermail/ovs-discuss/2022-May/051821.html
[2]
https://patchwork.ozlabs.org/project/ovn/patch/20220511142757.168196-1-lmartins@redhat.com/
Partial-Bug: #1971431
Change-Id: Ia041f640293ba26abf9f70af915817e9861e8ffc
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
In Zed cycle, we have dropped the python 3.6/3.7[1] testing
and its support. Add release notes and update the python
classifier for the same.
[1] https://governance.openstack.org/tc/reference/runtimes/zed.html
Change-Id: I8a10b462868f8c015fec3bee5622c41833b06e08
This patch adds a new configuration variable to control the OVS
OpenFlow rule processing operations:
* ``openflow_processed_per_port``: by default "False". If enabled,
all OpenFlow rules associated to a port will be processed at once,
in one single transaction. If disabled, the flows will be processed
in batches of "AGENT_RES_PROCESSING_STEP=100" number of OpenFlow
rules.
With ``openflow_processed_per_port`` enabled, all Firewall
OpenFlow rules related to a port are processed in one transaction
(executed in one single command). That ensures the rules are written
atomically and apply all of them at the same time.
That means all needed rules to handle the ingress and egress traffic
of a port using the Open vSwitch Firewall, are committed in the OVS
DB at the same time. That will prevent from partially applied OpenFlow
sets in the Firewall and inconsistencies when applying new SG rules or
during the OVS agent restart.
That will override, if needed, the hard limit of
"AGENT_RES_PROCESSING_STEP=100" OpenFlow rules that could be
processed in OVS at once.
If the default configuration values are not modified, the behaviour of
the OVS library does not change.
Closes-Bug: #1934917
Change-Id: If4984dece266a789d607725f8497f1aac3d73d23
Today Nova updates the mac_address of a direct-physical port to reflect
the MAC address of the physical device the port is bound to. But this
can only be done before the port is bound. However during migration Nova
is not able to update the MAC when the port is bound to a different
physical device on the destination host.
This patch extends port binding logic for direct-physical ports to allow
providing the MAC address of the physical device via the binding profile.
If it is provided then Neutron overwrites the value of the mac_address
field of the port with the value from the active binding profile.
Also when the port is being unbound or the MAC address is removed from
the active binding porfile then neutron resets the mac_address field of
port to a generated MAC to avoid duplicated MAC issues when another port
is being bound to the same physical device.
The shim API extension for this change is being proposed in
I54b4c85ffc4856fba7ad5e9e29f77f74815e1275 in neutron-lib.
Depends-On: https://review.opendev.org/c/openstack/neutron-lib/+/831935
Closes-Bug: #1942329
Change-Id: Ib0638f5db69cb92daf6932890cb89e83cf84f295
This patch enables the gateway IP network QoS inheritance in
the OVN backend driver. The OVN QoS extension will use the
router external network (GW network) QoS policy if the gateway
IP port has no QoS policy assigned.
Partial-Bug: #1950454
Change-Id: I5ee51dc124ae464b9e9fd366cf7bf85176376c25
When OVN is clustered, connection be set multiple addresses, inactivity
probe cannot currently be set correctly. this patch fix it.
Closes-bug: #1958364
Change-Id: I5f83d6f47dc60b849cca5830ec3f77c15a446530
Enabled ``DbQuotaDriverNull`` as a productio quota database
quota driver. This driver does not enforce any quota nor have access
to the database. When using this quota driver, the API will return
the default empty values expected from the ``QuotaDriverAPI`` class.
Closes-bug: #1960032
Change-Id: Iafa24753e657746a8b8165b5a63c17de9a9ba791
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
Co-Authored-By: Rodolfo Alonso Hernandez <ralonsoh@redhat.com>
The validation is intended mostly for tests and don't make much sense
when running the migration in production because likely there are
already running workloads. This patch changes the default to False so
migration validation must be explicitly asked for.
Change-Id: I5470f61a5e0b55bf682526208c3f57dc0ca6ffd5
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
Extension "uplink-status-propagation" does not allow to modify existing
ports. This extension only enables the creation of new ports with
this new flag.
Similar to [1], this patch changes the default behaviour of the
exiting ports: if no "propagate_uplink_status" flag is present, "True"
is returned now. The aim of this change is to enable this feature for
all existing ports, that is usually the aim of an administrator when
enables this extension.
[1]https://bugs.launchpad.net/neutron/+bug/1888487
Closes-Bug: #1967881
Related-Bug: #1888487
Change-Id: Ica5b76e0a9a5ae12f764c66be259d7f3cd5b248b
This patch implements router gateway IP QoS based on meter,
using the existing plugin and extension, only the driver side
is different.
Closes-Bug: #1893625
Co-Authored-By: zhanghao <hao.zhang.am.i@gmail.com>
Co-Authored-By: Rodolfo Alonso Hernandez <ralonsoh@redhat.com>
Change-Id: I46864b9234af64f190f6b6daebfd94d2e3bd0c17
Add file to the reno documentation build to show release notes for
stable/yoga.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/yoga.
Sem-Ver: feature
Change-Id: I83a7081a2aaaa0cc4812ba823a9a91f48149556c
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