Sometimes, the methods ``NeutronObject.get_object`` and
``ResourcesPushRpcApi.push`` yield the GIL during the execution.
Because of that, the thread in charge of sending the RPC information
doesn't finish until other operation is pushed (implemented in [1]).
By making the RPC cast synchronous with the update/delete events, it
is ensured that both operations will finish and the agents will receive
the RPC event on time, just after the event happens.
This issue is hitting more frequently in the migration to the WSGI
server, due to [2]. Once the eventlet library has been deprecated from
OpenStack, it will be possible to use the previous model (using a long
thread to handle the RCP updates to the agents). It is commented in the
code as a TODO.
This patch is temporarily reverting [3]. This code should be restored
too.
[1]https://review.opendev.org/c/openstack/neutron/+/788510
[2]https://review.opendev.org/c/openstack/neutron/+/925376
[3]https://review.opendev.org/c/openstack/neutron/+/824508
Closes-Bug: #2077790
Related-Bug: #2075147
Change-Id: I7b806e6de74164ad9730480a115a76d30e7f15fc
First, explain where the repos should be checked out to. Second,
recommend rebooting with the latest distro kernel to avoid ovs module
incompabitilities.
Change-Id: I480ba689a4e20f373e30fe77059474b6dbea5a72
This reverts commit ffaf021810fcd8132582de544d3c324c3cc43b95.
Reason for revert: Fixed in oslo.serialization==5.5.0
Depends-On: https://review.opendev.org/c/openstack/requirements/+/926373
Change-Id: Ie09e230447f80b53a31bd1dad26e7f1722df2f30
In a Neutron server, there are workers that are not spawned in a single
process. These processes are grouped and spawned within a service class
called ``AllServicesNeutronWorker``. This class spawns a thread per
service worker. That reduces the footprint of the Neutron server,
reducing the number of processes spawned.
Depends-On: https://review.opendev.org/c/openstack/neutron-lib/+/922085
Related-Bug: #2069595
Change-Id: I24313dc891f179a600909854dd8f9a09f74088f5
When an IPv6 only network is used as the sole network for a VM and
there are no other bound ports on the same network in the same chassis,
the OVN metadata agent concludes that the associated namespace is not
needed and deletes it. As a consequence, the VM cannot access the
metadata service. With this change, the namespace is preserved if there
is at least one bound port on the chassis with either IPv4 or IPv6
addresses.
Closes-Bug: #2069482
Change-Id: Ie15c3344161ad521bf10b98303c7bb730351e2d8
Required since the Depends-On patch included, without
it postgres job fails with:-
AttributeError: 'NoneType' object has no attribute 'id'
Depends-On: https://review.opendev.org/c/openstack/neutron-lib/+/923926
Related-Bug: #2072567
Change-Id: I8f2229eb0a9d8dce927ded004037eda93ce3650d
Until the required fixes lands and release temporary
mark the job non-voting to unblock neutron gate.
Related-Issue: #2076430
Change-Id: I1044a5613e960bc24d63b7268f891abf1f223d28
By default abandon_old_reviews.sh script will now ignore
patches from any unmaintained branches.
Cleanup of those patches can be done by passing "--unmaintained"
parameter to the script
Change-Id: If7626543f9095196ef1515039f153b16282c27a4
Some of the OVN maintenance tasks are expected to be run just once and
then they raise periodic.NeverAgain() to not be run anymore. Those tasks
also require to have acquried ovn db lock so that only one of the
maintenance workers really runs them.
All those tasks had set 600 seconds as a spacing time so they were run
every 600 seconds. This works fine usually but that may cause small
issue in the environments were Neutron is run in POD as k8s/openshift
application. In such case, when e.g. configuration of neutron is
updated, it may happen that first new POD with Neutron is spawned and
only once it is already running, k8s will stop old POD. Because of that
maintenance worker running in the new neutron-server POD will not
acquire lock on the OVN DB (old POD still holds the lock) and will not
run all those maintenance tasks immediately. After old POD will be
terminated, one of the new PODs will at some point acquire that lock and
then will run all those maintenance tasks but this would cause 600
seconds delay in running them.
To avoid such long waiting time to run those maintenance tasks, this
patch lowers its spacing time from 600 to just 5 seconds.
Additionally maintenance tasks which are supposed to be run only once and
only by the maintenance worker which has acquired ovn db lock will now be
stopped (periodic.NeverAgain will be raised) after 100 attempts of
run.
This will avoid running them every 5 seconds forever on the workers
which don't acquire lock on the OVN DB at all.
Closes-bug: #2074209
Change-Id: Iabb4bb427588c1a5da27a5d313f75b5bd23805b2
Setting of the 'reside-on-chassis-redirect' was skipped for LRP ports of
the provider tenant networks in patch [1] but later patch [2] removed
this limitation from the ovn_client but not from the maintenance task.
Due to that this option wasn't updated after e.g. change of the
'enable_distributed_floating_ip' config option and connectivity to the
existing Floating IPs associated to the ports in vlan tenant networks
was broken.
This patch removes that limitation and this option is now updated for
all of the Logical_Router_Ports for vlan networks, not only for external
gateways.
[1] https://review.opendev.org/c/openstack/neutron/+/871252
[2] https://review.opendev.org/c/openstack/neutron/+/878450
Closes-bug: #2073987
Change-Id: I56e791847c8f4f3a07f543689bf22fde8160c9b7
It was observed in the tempest tests that the port could be already
deleted by some other concurrent event when the `run` is called.
This caused a flood of exception logs. Thus, with this patch we only
query for the port and only update_router_port when the port was
found.
Closes-Bug: #2073567
Change-Id: I54d027f7cb5014d296a99029cfa0a13a7800da0a
Since [1], it is possible to define a set of RBAC actions to filter the
model query. For "network" and "subnet" models, it is needed to add the
RBAC action "access_as_external" to the query. Instead of adding an
additional filter (as is now), this patch replaces the default RBAC
actions used in the model query, adding this extra one.
The neutron-lib library is bumped to version 3.14.0.
[1]https://review.opendev.org/c/openstack/neutron-lib/+/914473
Closes-Bug: #2059236
Change-Id: Ie3e77e2f812bd5cddf1971bc456854866843d4f3
A number of things were moved to neutron-lib earlier
this year, start using them throughout the tree.
Added tests to cover TYPE_GRE_IP6 usage in
get_gre_tunnel_port_type() as I noticed it was
untested.
TrivialFix
Change-Id: Idceb1bc4ba7de3b007a5c2fac28df7659166438c
This patch adds short document with description of the roles supported
by the default Neutron's API policies.
Change-Id: Id8106478fc32cd2da283fa4b5763d535372127a6
Removed the tenant_id/project_id parameter from any QoS rule command
in the fullstack framework.
Closes-Bug: #2074360
Related-Bug: #2022043
Change-Id: I18efb28ffc02323e82f6b116a3f713cb9e2a132e
Neither fdb_removal_limit nor mac_binding_removal_limit config
options currently get set in the OVN DB. This patch corrects that
and adds missing testing for the MAC_Binding aging maintenance
task.
Fixes: 0a554b4f29 ("Add support for OVN MAC_Binding aging")
Fixes: 1e9f50c736 ("Add support for FDB aging")
Closes-Bug: #2073309
Change-Id: I80d79faeb9f1057d398ee750ae6e246598fd13d2
The "tagging" service plugin API extension does use the policy enforcer
since [1]. If a tag API call is done just after the Neutron server has
been initialized and the policy enforcer, that is a global variable per
API worker, has not been initialized, the API call will fail.
This patch initializes the policy enforcer as is done in the
``PolicyHook``, that is called by many other API resources that inherit
from the ``APIExtensionDescriptor`` class.
[1]https://review.opendev.org/q/I9f3e032739824f268db74c5a1b4f04d353742dbd
Closes-Bug: #2073782
Change-Id: Ia35c51fb81cfc0a55c5a2436fc5c55f2b4c9bd01
The multithread processing does not add any speed improvement to the
event processing. The aim of this patch is to reduce to 1 the number of
threads processing the ``IpConntrackManager`` events.
Closes-Bug: #2073745
Change-Id: I190d842349a86868578d6b6ee2ff53cfcd6fb1cc
The method ``ProcessMonitor._check_child_processes`` was releasing
the thread executor inside a method that creates a lock for the resource
"_check_child_processes". Despite this resource is not used anywhere
else (at least for this instance), this could lead to a potential
deadlock.
The current implementation of ``lockutils.synchronized`` with the
default value "external=False" and "fair=False" is a
``threading.Lock()`` instance. The goal of this lock is, precisely, to
execute the code inside the locked code without any interruption and
then to be able to release the executor.
Closes-Bug: #2073743
Change-Id: I44c7a4ce81a67b86054832ac050cf5b465727adf
