This is follow-up of 0a554b4f29a800694539b285c75eb7f8a2a69193 and fixes
the wrong option name mentioned in the release note file.
Change-Id: I5fd200c1352aaed8cff1d4a857967f5e32e45db7
A logical router port in an external tunnelled network won't be
scheduled in any chassis. A tunnelled network has no physical
provider network associated thus the logical router port cannot
be bound to a specific chassis.
Related-Bug: #2019217
Change-Id: I140c22899ea3b0240f8c30902fc2dc7055914a18
api_workers=0 does not disable api workers but neutron-server still
launches one api worker. Rejecting 0 helps user notice that the value
they request in config files is not honored.
Also the other rpc workers options disable the corresponding workers
completely by setting these options to 0, so setting negative values
work but does not bring any special benefit.
Change-Id: Iac16b241c71ac1068c6fbea3cc792b74bfc66c03
Currently at least 1 rpc worker is launched even when a user requests
zero workers by setting rpc_workers=0. The setting of rpc_workers=0 is
used when ml2-ovn plugin is used without any additional agent, and in
this deployment pattern the single rpc worker is not at all used.
This change ensures no rpc worker is launched when rpc_workers options
is explicitly set to 0. This may be classified as a breaking change,
but is consistent with the earlier change[1] for rpc_workers=0.
[1] 3e1e2d63b3383d28c9a36b00000ab89caffa3829
Closes-Bug: #2052484
Change-Id: I878e50c3192ecd3b145ded0ab8394845a089696e
This patch adds info about the fact that FIP PFs aren't working when
in the ML2/OVN backend distributed routing is enabled and provider
networks are added to the router as internal networks.
Related-Bug: #2028846
Change-Id: I3a0ab43c52a3090257a1accaee00f33abff54e74
This is follow up patch to [1] in which was added warning about
incompatible configuration of the vlan/flat networks allowed as tenant
networks, distributed routing and port forwardings.
In this new patch similar warning is logged every time when port
forwarding is created using router which have actually connected vlan or
flat networks as "internal networks" (external gateway network is fine)
and when distributed routing is enabled in the Neutron config.
This patch additionally adds "neutron:is_ext_gw" flag to the
Logical_Router_Port's external_ids. With that it's easier to check if
network is used as gateway network (no checks needed) or not (checks are
perfomed and warning may be logged).
[1] https://review.opendev.org/c/openstack/neutron/+/892542
Related-Bug: #2028846
Change-Id: I101128bdb421ec83df5cdcb0d486cbafbbca2ce5
Currently routers with ha=true are NOT rescheduled form a dead L3 agent, even
when `allow_automatic_l3agent_failover` is enabled.
This is contrary to what the user expects and the feature description states:
"Automatically reschedule routers from offline
L3 agents to online L3 agents."
There is no distinction made between HA and non-HA routers. Also HA and
automatic-failover can work together:
* HA allows for a fast failover to a standby router
* Automatic failover then restores back full redundancy in case the failed L3
agent, which HA failed away from, does not come back within a certain time.
Closes-Bug: #2050236
Change-Id: I1e5ee5048f61eef7fa4d9de25e69bf0e0a5ea442
This new section describes how the OVN L3 schedulers distribute
the ``Chassis`` candidate list among the Available Zones, in
order to provide more resilience to the L3 HA: if the active
LRP binding fails, the next in the list will belong to another
AZ.
Related-Bug: #2030741
Change-Id: I20aaeefb33c424dc1a9c13f94f2912d0fa973166
Since [1], we introduced a way to skip the load of the OVO synthetic
fields depending on the resource fields retrieved. In the case of the
security groups (SG), the SG rules are child objects to the SGs. The SG
rules are retrieved when a SG OVO is created.
The improvement done in [1] is to make the SG rules load dynamically,
that means using the load mode "lazy='dynamic'". That will issue a SQL
query only if the SG rules are read; if not, the query is never issued.
However since [2] (and this is previous to the [1] optimization), we
always add the field "shared" to the filters and thus to the fields to
retrieve, because it is a policy required field. Because "shared" is a
synthetic field [3], that will force the SG "synthetic_fields" load and
the retrieval of the SG rules always. This is undoing any performance
improvement.
This patch is changing the loading method to "joined"; that will request
the SG rules in the same SQL query, instead of issuing separate queries
for the SG rules. Until a method to load the SG "shared" field,
independently of the synthetic OVO fields is implemented, this change
will improve the SG retrieval performance. In a testing environment
with around 5500K SG and 4 rules (default ones) per SG:
* lazy='dynamic': 38 seconds
* lazy='select': 20 seconds
* lazy='joined': 12 seconds
[1]https://review.opendev.org/q/topic:%22bug/1810563%22
[2]https://review.opendev.org/c/openstack/neutron/+/328313
[3]b85b19e384/neutron/objects/rbac_db.py (L349)
Related-Bug: #2052419
Change-Id: I300464472f2348d148f2a3ddac384c883d9d815b
Currently both RpcReportsWorker and RpcWorker are launched with
the same process title("rpc worker"), and we can't distinguish one from
the other.
This changes the process title of RpcReportsWorker, so that we can
find the worker used by RpcReportsWorker, not by RpcWorker.
Change-Id: I610a00667762bbdd45bc72c5a865694b92cfd45a
This new document adds:
* A definition of the OVN L3 scheduler
* A description of the different OVN L3 schedulers
* How the LRP are re-scheduled if the gateway chassis list
changes.
Related-Bug: #2023993
Change-Id: Idcc0e34227e47df53a1f395c8fd163723d54b933
Update hacking to a more recent version, along with
flake8-import-order.
Remove N347 (import mock library) check as that is the
default with later hacking versions.
Update the builtins override of '_' to be the neutron.i18n
version due to the code triggering a false positive. This
is done in a couple of other projects as well.
Fix a number of new warnings it found.
Added some ignore directives for new whitespace issues
found in the test tree, can fix later.
TrivialFix
Change-Id: I5923255af86cf1fa11ab8e3b03bb9efac7dd7b58
The method test calling ``_post_request`` with create or update
operations, were not properly patching the ML2 plugin
``create_network`` and `update_network`` methods. With
Python3.12, the mock object passed (instead of a dictionary with a
reduced network definition) don't have a ``__json__`` method and
fails during the encoding.
NOTE: this has been manually tested with Python3.12. Currently this
patch cannot be tested in the CI.
Closes-Bug: #2051928
Change-Id: Ie30af0c655d2f27d9039ff7933e81603047da6f4
In case when port_forwarding service plugin is enabled and vlan or flat
network (provider network types) is configured as one of the
tenant_network_types in the ML2 config there is an issue with
centralized and distributed traffic.
FIP port forwarding in ovn backend are implemented as OVN Load balancers
thus are always centralized but if "enable_distributed_floating_ip" is
set to True, FIPs are distributed. And in such case it won't work as
expected as either it tries to send FIP PF's traffic as distributed when
"reside-on-redirect-chassis" for LRP is set to "false" or
tries to centralized everything (even FIP which should be distributed)
when "reside-on-redirect-chassis" is set to "true".
It's not really easy to avoid that issue from the code so this patch
adds warning in the upgrade checks and also log warning about it during
start of the neutron server process to at least warn cloud admin that
such potential issue may happen in the cloud.
Related-Bug: #2028846
Change-Id: I398f3f676c59dc794cf03320fa45efc7b22fc003
tox now always recreates an env although the env is shared using envdir
options.
~~~
$ tox -e genpolicy
genpolicy: recreate env because env type changed from
{'name': 'genconfig', 'type': 'VirtualEnvRunner'} to
{'name': 'genpolicy', 'type': 'VirtualEnvRunner'}
~~~
According to the maintainer of tox, this functionality is not intended
to be supported.
https://github.com/tox-dev/tox/issues/425#issuecomment-1011944293
Change-Id: Ibbb4ab56ca84f5a8f9fe309a46469d49ff4ef9f7
This function is private. This commit also adds missing unit tests.
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: I6d3e75fb61a90358cf7afbe165181d3da6363bfb
Usage of the helper function which retrieves the name of the process
based on the usage of the segments was missing for unregister which
leads an issue when disabling dhcp agent for a network.
Closes-Bug: #2051690
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: Ic6e999214210383f17c29982bf5673eea1bb55c0
The method ``_get_nets_and_ipv6_ra_confs_for_router_port`` can be called
from a non-admin user request, when updating or creating a local router
port. If the router external gateway network is "external" (as it should
be) but is not explicitly shared (a network RBAC with action
"access_as_shared"), the user won't retrieve the corresponding subnet.
NOTE: is is *not* needed to apply both "access_as_shared" and
"access_as_external" RBACs to a network. Please read c#1 in the LP bug
for more context.
Related-Bug: #2051831
Change-Id: I161f1a6021c0da2d0063f8cb249b3bb9d7b6d5ae
openstack-tox-py311-with-sqlalchemy-master started
failing after commit bf2f8342d, which updated code
to use oslo_utils.timeutils.utcnow(). Since getting
admin context calls timeutils, move the reset_mock()
to be right after.
Trivialfix
Change-Id: Id42ffb7b3110869936319bf3c403d1958daee706
Since [1], the method ``timeutils.utcnow`` is called from
``neutron_lib.context.ContextBase.__init__`` too. Although this patch is
still not released (current last neutron-lib version is 3.10.0), this
is affecting "openstack-tox-py311-with-sqlalchemy-master" that is using
neutron-lib master branch.
[1]https://review.opendev.org/c/openstack/neutron-lib/+/903841
Closes-Bug: #2051501
Change-Id: I1b2dd06d12dffd95869508167f8682e4042c044e
Update l3 ovn schedulers (chance, leastloaded) to ensure that LRP gateways are distributed over chassis in the different eligible AZs.
Previous version already ensure that LRP gateways were scheduled over chassis in eligible AZs. But, depending on the deployment characteristics, all these chassis could be in the same AZ. In some use-cases, it could be needed to have LRP gateways in different AZs to be resilient on failures.
This patch re-order the list of eligible chassis to add a priority on selecting chassis in different AZs.
This should provide a solution for users who need to have their router gateways scheduled on chassis from different AZs.
Closes-Bug: #2030741
Change-Id: I72973abbb8b0f9cc5848fd3b4f6463c38c6595f8