Synchronise 2023.1 with upstream #171
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}
Commit 260c968 broke the gate by causing jobs to not get run when it added RE2 compatibility for irrelevant-files. Digging found that RE2 doesn't support negative lookahead (and won't ever), so it's impossible to replace the previous pcre filter with a similar RE2 filter. Instead of reverting to the original filter, which is considered obsolete by zuul, this patch fixes the issue by explicitly listing all files under zuul.d/ except the one that we actually want to trigger the jobs: zuul.d/project.yaml. Listing all the files in the directory for every job is not ideal, and we may revisit it later, or perhaps even reconsider the extensive use of irrelevant-files in the neutron tree. This will have to wait for when the gate is in better shape though. [0] google/re2#156 Conflicts: zuul.d/job-templates.yaml zuul.d/project.yaml Related-bug: #2065821 Change-Id: I3bba89ac14414c6b7d375072ae92d2e0b5497736 (cherry picked from commit 11027e3) (cherry picked from commit 0afdfb0) (cherry picked from commit af8d615)
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 Conflicts: neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py Closes-bug: #2073987 Change-Id: I56e791847c8f4f3a07f543689bf22fde8160c9b7 (cherry picked from commit 4b1bfb9)
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.
Conflicts:
neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/maintenance.py
Closes-bug: #2074209
Change-Id: Iabb4bb427588c1a5da27a5d313f75b5bd23805b2
(cherry picked from commit 04c217b)
(cherry picked from commit 78900c1)
(cherry picked from commit 9108218)
…nance task" into stable/2023.1
…e run once" into stable/2023.1
Taking example of a network that have multiple rbacs. In a situation of selecting networks that are shared to a project. If we could could already match the one that are owned by the context we can expect les rbacs to scan. https://bugs.launchpad.net/neutron/+bug/1918145/comments/54 In an environement with about 200 00 rbacs and 200 networks this reduce time of the request from more than 50s to less than a second. Related-bug: #1918145 Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com> Change-Id: I54808cbd4cdccfee97eb59053418f55ba57e11a6 Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com> Change-Id: Ib155fbb3f6b325d10e3fbea201677dc218111c17 (cherry picked from commit e6de524)
github-actions
bot
added
automated
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.