This patch fixes 2 issues related to that port_hardware_offload_type
extension:
1. API extension is now not supported by the ML2 plugin directly so if
ml2 extension is not loaded Neutron will not report that API
extension is available,
2. Fix error 500 when creating port with hardware_offload_type
attribute set but when binding:profile is not set (is of type
Sentinel).
Closes-bug: #2078432
Closes-bug: #2078434
Change-Id: Ib0038dd39d8d210104ee8a70e4519124f09292da
When ovn_router_indirect_snat = True, ml2/ovn will set a catch-all snat
rule for each external ip, instead of a snat rule per attached subnet.
NB: This option is global to cluster and cannot be controlled per
project or per router.
NB2: this patch assumes that 0.0.0.0/0 snat rules are properly handled
by OVN. Some (e.g. 22.03 and 24.03) OVN versions may have this scenario
broken. See: https://issues.redhat.com/browse/FDP-744 for details.
--
A long time ago, nested SNAT behavior was unconditionally enabled for
ml2/ovs, see: https://bugs.launchpad.net/neutron/+bug/1386041
Since this behavior has potential security implications, and since it
may not be desired in all environments, a new flag is introduced.
Since OVN was deployed without nested SNAT enabled in multiple
environments, the flag is set to False by default (meaning: no nested
SNAT).
In theory, instead of a config option, neutron could introduce a new API
to allow users to control the behavior per router. This would require
more work though. This granular API is left out of the patch. Interested
parties are welcome to start a discussion about adding the new API as a
new neutron extension to routers.
--
Before this patch, there was an alternative implementation proposed that
was not relying on 0.0.0.0/0 snat behavior implemented properly in OVN.
The implementation was abandoned because it introduced non-negligible
complexity in the neutron code and the OVN NB database.
See: https://review.opendev.org/c/openstack/neutron/+/907504
--
Closes-Bug: #2051935
Co-Authored-By: Brian Haley <haleyb.dev@gmail.com>
Change-Id: I28fae44edc122fae389916e25b3321550de001fd
We needed to declare get_noscope_ipv6() on ipv6_netutils in Neutron
while this function was made avaliable in oslo.utils. This is not needed
anymore.
Related-Bug: #2073894
Change-Id: I76a1c9f75906e8c0bd0ad368c55f01d58811b42d
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
... because windows support was removed by [1].
[1] 5d316e8a876baf80b253d799dcd6f82dc8c526ce
Related-Bug: #2015844
Change-Id: I4d60d9faed2ad5862777b38709dcb754f2827a3b
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
The Neutron owned Static Routes created in the OVN database are marked
with the external_ids key neutron:is_static_route. This mark will be used
by the OVN DB sync tool to distinguish the Neutron created Static Routes
from those added externally; the second ones should not be altered during
the sync process. The static route update task runs only once during the
maintenance task, and if all entries are already configured, no action is
performed.
Related-bug: #2027742
Change-Id: I4226024cb4cfd85bdf4f717d42d48150cab22442
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
A formatting error can sometimes be seen in the l3-agent
log while spawning the state change monitor if the pid
file is empty. Log a warning to that effect instead so
an admin is aware in case there is an issue observed
with the router.
Closes-bug: #2077351
Change-Id: Ic599c2419ca204a5e10654cb4bef66e6770cbcd7
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
Currently, is_valid_ipv6 accepts ipv6 addresses with scope. However
netaddr library won't accept an address with scope. Now,
get_noscope_ipv6() can be used to avoid this situation. In a future we
will be able to use the same function which is also being defined on
oslo.utils. https://review.opendev.org/c/openstack/oslo.utils/+/925469
Closes-Bug: #2073894
Signed-off-by: Elvira García <egarciar@redhat.com>
Change-Id: I27f25f90c54d7aaa3c4a7b5317b4b8a4122e4068
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
