Synchronise 2023.1 with upstream #123
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
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]https://github.com/openstack/neutron/blob/b85b19e3846fa74975ba5d703336b6e7cd8af433/neutron/objects/rbac_db.py#L349 Related-Bug: #2052419 Change-Id: I300464472f2348d148f2a3ddac384c883d9d815b (cherry picked from commit 52662ca)
Grenade skip level jobs reference stable/yoga but that branch was renamed to unmaintained/yoga Change-Id: Ifdfa194a95a39c63ec61f2afe030fed108de5a77 Related-Bug: #2052915
Related-Bug: #1792901 Change-Id: I6b2e86cd252c345b25583651152009baa3320f19 (cherry picked from commit 1600d54)
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.
Conflicts:
neutron/cmd/upgrade_checks/checks.py
neutron/common/ovn/utils.py
neutron/tests/unit/cmd/upgrade_checks/test_checks.py
Related-Bug: #2028846
Change-Id: I398f3f676c59dc794cf03320fa45efc7b22fc003
(cherry picked from commit ce53fb5)
(cherry picked from commit 1c6d3d448d419d6176647dc0e50760c19d3fefcb)
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 Conflicts: neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/maintenance.py neutron/tests/unit/services/ovn_l3/test_plugin.py Related-Bug: #2028846 Change-Id: I101128bdb421ec83df5cdcb0d486cbafbbca2ce5 (cherry picked from commit a355d2a) (cherry picked from commit 3eaa326)
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.
Conflicts:
doc/source/ovn/gaps.rst
Related-Bug: #2028846
Change-Id: I3a0ab43c52a3090257a1accaee00f33abff54e74
(cherry picked from commit cce872e)
(cherry picked from commit 8748557)
… Neutron" into stable/2023.1
…nto stable/2023.1
… gaps" into stable/2023.1
github-actions
bot
added
automated
mnasiadka
approved these changes
Feb 19, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains a snapshot of 2023.1 from upstream stable/2023.1.