Since OVN 21.03.0 [1], ovn-controller no longer will try to reuse the
stale Chassis/Chassis_Private records but will try to create new ones.
If the stale records have no been manually deleted and ovn-controller
tries to register a new Chassis with the same values, the transaction will
fail.
[1]fc359bfe93
Closes-Bug: #2073613
Change-Id: I2f14558b0910fed03fe0243c4daa33947feeedcb
After the execution of an RPC event received, the DHCP agent will log
the number of pending events stored in ``DhcpAgent._queue``, that is a
``ResourceProcessingQueue`` instance.
This patch also improves the ``DictModel`` class. When an instance of
this class is printed in a log message, the ``__repr__`` method will
call the ``__str__`` method, that returns the key/values stored in the
local dictionary.
Closes-Bug: #2073490
Change-Id: I69dc6235f7599b687e49428aaa02c4b70154f393
The plugin was removed almost 10 years ago. The doc part is confusing
as current operators may understand it as the mechanism driver.
TrivialFix
Change-Id: I2a76002d57f42e10cdf45f3c5bba787d1845152b
The RPC workers process was not correctly logging the current number of
processes created. If the config variable "rpc_workers" is not defined,
the default "None" value will be used and the number of RPC workers
will be calculated depending on the configured API workers and the
number of CPUs in the system.
Trivial-Fix
Change-Id: I64f0098fda1e2f989c255cc0a7f295e0939b8b75
Added a new extension called "subnet-external-network". This extension
adds a new field to the subnet resource: "router:external". It is named
after the field "router:external" in the network resource. The subnet
inherits the value form the network it belongs.
Subnet OVO: the subnet OVO receives a new field called "external", same
as the network OVO. It is a synthetic field inherited from the network
one.
Filter query: same as the network database query, the subnet database
query receives a new extra filter to add the action
"access_as_external", inherited from the network RBAC. It is needed
to be able to retrieve these subnets that belong to external network
and thus visible by a non-admin user.
The minimum neutron-lib version required is 3.11.0 that contains the
patch [1].
[1]https://review.opendev.org/c/openstack/neutron-lib/+/907949
Depends-On: https://review.opendev.org/c/openstack/tempest/+/922938
Depends-On: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/922711
Depends-On: https://review.opendev.org/c/openstack/neutron-lib/+/912273
Closes-Bug: #2051831
Change-Id: Ice91de9ae7f82b983579272af6e2bf10c3a02dbf
The method ``DhcpAgent._dhcp_ready_ports_loop`` is updating the
instance variables ``dhcp_prio_ready_ports`` and ``dhcp_ready_ports``.
These variables are also updated by the ``sync_state`` method (that
performs an update of the current status of a network). The related
method should be executed inside a context lock to avoid interferences
from other threads.
NOTE: this patch is similar to [1] (that was correctly reverted in [2]
due to the high error rate in the CI). This new patch changes the
decorator method for the ``dhcp_ready_ports_loop``. The method no longer
retrieves the sync lock in write mode but in read mode. It will need to
wait only if the syncing method is running; otherwise, it will be
allowed to run and modify ``self.dhcp_prio_ready_ports`` and
``self.dhcp_ready_ports``.
[1]https://review.opendev.org/c/openstack/neutron/+/923625
[2]https://review.opendev.org/c/openstack/neutron/+/924213
Related-Bug: #2070376
Change-Id: Ic132dc49142b380f1752c9307b50afd1ce2378b0
During a network creation, the code added to support multiple network
segments [1] was first disabling any existing DHCP namespace (including
the namespace deletion, the driver removal and the DHCP port deletion)
and the re-creating it again. The execution of both actions one after
the other was triggering a race condition where the DHCP namespace was
left without the DHCP port.
[1]https://review.opendev.org/c/openstack/neutron/+/840421
Closes-Bug: #2073464
Change-Id: Ic688d1c721511868b7bd9943bb679c4cb91b1a60
In the ``TestNbApi`` tests, make the Logical_Router name random.
This patch also makes use of the ``lookup`` method to retrieve
a DB row from the database.
Closes-Bug: #2073387
Change-Id: I304c5199815ff583ac306f4de6cea771fdf00391
This reverts commit 928f41f1feac6511b4bb67e6211b4f06a9b7ca56.
Reason for revert: Jobs failing randomly as mentioned in lp#2073251
Change-Id: Ib4ea8a31f785cd52407c1aa241501046e5e295e2
Related-Bug: #2070376
Related-Bug: #2073251
If northd is very busy, it may happen port is deleted when handling an
LSP down event causing standard attribute being gone when bumping ovn
revision number. This is because the port is set down in SB DB first and
then northd propagates that to NB DB, and then the event is emited.
This patch just makes sure the traceback is not printed in case this
happens.
TrivialFix
Closes-bug: #2069442
Change-Id: I7d21e4adc27fab411346e0458c92191e69ce6b30
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
This patch introduces a new configuration option for OVN called
"broadcast_arps_to_all_routers". This option is responsible for
configuring the external networks with the 'broadcast-arps-to-all-routers'
configuration from OVN 23.06 and newer. By enabling this option (default)
OVN will flood ARP requests to all attached ports on a network. If
disabled, ARP requests are only sent to routers on that network if the
target MAC address matches. ARP requests that does not match a router
will only be forwarded to non-router ports.
Closes-Bug: #2071818
Change-Id: Id16b16113420e9f024e1936f9427824d711b6d30
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Support for IPv6 iPXE chainloading [0] and Neutron integration [1] has
already landed.
This patch updates the Baremetal provisioning guide to reflect on these
changes.
[0] c5fd51bd15
[1] https://review.opendev.org/c/openstack/neutron/+/890683
Change-Id: I58390ec957146da3de84ef2bbc88e409360945d1
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Currently the check will use /usr/bin/tcpdump only for Ubuntu 22.04
(jammy) but it will try to use the old /usr/sbin/tcpdump path for newer
versions of Ubuntu such as 24.04 (noble) which causes the br-ex-tcpdump
service to fail to start in jobs that enable it (like multinode):
systemd[1]: devstack@br-ex-tcpdump.service: Main process exited,
code=exited, status=203/EXEC
This uses 'which' to find the path and if it is not found, use the
current check in case there is anything relying on it.
Change-Id: I034e8ca87909521c7e4f3e49996144f9c80d416d
This patch adds support for the MANAGER role in the Neutron API's
policies.
It also adds unit tests to cover MANAGER role privileges in all APIs.
This is implementation of the phase 3 of the Secure RBAC community goal
[1]
[1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#phase-3
Change-Id: I377449050cb8aba56e167eba0981213831b8d7f2
The access to ``row.data`` is not recommended, instead of this it is
possible to iterate through a table items directly over the row
elements.
Related-Bug: #2072545
Change-Id: I24f7bb355d2e79ec6104569903e7d852933393a1
All the ML2/OVS tempest jobs are now using the WSGI API
module, instead of the eventlet server.
Related-Bug: #2069581
Topic: eventlet-deprecation
Change-Id: I35d700885e6de0f1b92537789ae9819f8b21db0c
Some unit tests related to the DHCP agent are calling the
``MetadataDriver`` destroy method. This method has an active waiting
timeout to check if the process is still active, defined by
``driver_base.SIGTERM_TIMEOUT``. This patch sets this variable to 0
seconds during the unit tests to avoid the unnecessary waiting.
Trivial-Fix
Change-Id: I05174fdd5b46c11e64d9dbdf789d7125bdfd99f1
Since [1] (ovs==3.3.1), the row data result stored in
the data dictionary will be a one single item list, instead of
the item itself.
[1] https://is.gd/yElVoV
Closes-Bug: #2072545
Change-Id: Ie5642b4073c6c54aeec3896ebcd451badc3d64a8
The RPC events received by the client are stored in a queue and
processed depending on a priority. Before this patch, a pool of
threads was spawned to process the received events. However, this
model does not improve the processing speed and could lead to potential
thread concurrencies not considered. Note that the event processing
methods are thread safe against the sync method but not among them.
This patch reduce the number of concurrent threads processing the
received events to one only, that is safe against the sync process.
The network sync process could happen when:
* ``_dhcp_ready_ports_loop`` is called.
* ``sync_state`` is called.
Closes-Bug: #2070376
Change-Id: I21d237de97571aaaae3912d060a3e03a37dd20de
The method ``DhcpAgent._dhcp_ready_ports_loop`` is updating the
instance variables ``dhcp_prio_ready_ports`` and ``dhcp_ready_ports``.
These variables are also updated by the ``sync_state`` method (that
performs an update of the current status of a network). The related
method should be executed inside a context lock to avoid interferences
from other threads.
Related-Bug: #2070376
Change-Id: I49adc465a915883478c88f6d830f28dbc5d3b304
Currently when sriov agent is enabled and migrating a non-sriov
instance, non-sriov port status is frequently set to BUILD
instead of ACTIVE.
This is because the 'binding_activate' function in sriov-nic-agent sets it
BUILD with get_device_details_from_port_id(as it calls _get_new_status).
This patch checks network_ports in binding_activate and
skip binding port if it is not sriov port
Closes-Bug: #2072154
Change-Id: I2d7702e17c75c96ca2f29749dccab77cb2f4bcf4
If the DB connection is not stopped at the defined timeout (10 seconds),
the clean-up process will continue.
Closes-Bug: #2034589
Change-Id: I6c3b4da49364c3fed86053515e79121acac078d6
