The current comparison strategy is very time-consuming, and if
there are hundreds of thousands of security group rules, the
comparison time can still vary from several hours. The main
time-consuming operations are [1].
This patch is sorted first by security group rule ID and then
compared. The execution of sorting actions is relatively fast.
After actual measurement, the total time consumption is in the
minute level.
Partial-Bug: #2023130
[1] b86ca713f7/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_db_sync.py (L285-L291)
Change-Id: If4c886d928258450aac31e12a4e26e0cbe2ace62
We want this module for use elsewhere. This has a natural home in the
neutron.api module so move it there. This is similar to what has
previously been done for nova [1].
Tests for the module are also moved and other tests slightly decoupled.
[1] https://review.opendev.org/c/openstack/nova/+/902686
Change-Id: I835e7ad95b6d7d83d06f4303b476519c16b9a2c8
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
As was agreed on the CI meeting [1], this patch moves
neutron-ovn-grenade-multinode job from the experimental queue to the
check and gate queues.
Now in check/gate there are 2 grenade jobs: one ovs-multinode job and
one ovn-multinode job.
To not increase number of jobs in the check/gate, this patch also moves
neutron-ovs-grenade-dvr-multinode job to the periodic (and experimental)
queue.
[1] https://meetings.opendev.org/meetings/neutron_ci/2024/neutron_ci.2024-06-11-15.02.log.html#l-18
Change-Id: I22d0f9a59bca6f412dcf30005678229a859d5e4c
This reverts commit 85d3fff97e55ba85f72cda4365ad0441c10bd9f6.
Reason for revert:
The original change was made as a “cheap win” to optimize the number
of queries the neutron server makes during testing. This did
improve the number of queries made but introduced regression in
real world deployments where some customers(through automation)
would define hundreds of tags per port across a large deployment.
I am proposing to revert this change in favor of the old “subquery”
relation in order to fix this regression. In addition, I filed the
Related-Bug #2069061 to investigate using `selectin` as the more
appropriate long term solution.
Change-Id: I83ec349e49e1f343da8996cab149d76443120873
Closes-Bug: #2068761
Related-Bug: #2069061
This patch adds bump revision after updating the hostname
of a virtual port (more specifically its associated port).
This way there is no misalignment between the revision number
of Neutron DB and OVN DB.
It also avoids the unnecessary execution of the maintenance
task to simply match the revision_number.
Closes-Bug: #2069046
Change-Id: I2734984f10341ab97ebbdee11389d214bb1150f3
Will allow neutron to start using 'selectin' DB load
strategy and addresses some issues with netaddr library
related code.
Depends-on: https://review.opendev.org/c/openstack/requirements/+/921518
Change-Id: I1f4c3af87a2c997dbfb003e2d276df20fdf1d0d5
Creation of agents is not really supported and returns BadRequest
exception when called but without default policy for that call
oslo_policy module was using default rule for it and that default one is
'admin_or_owner' which is not correct in case of agent resource as it
don't belongs to any tenant so don't have owner.
Additionally it seems that BadRequest exception raised by the
create_agent method was missing resource and msg parameters so this
patch added them too.
Related-Bug: #2022043
Change-Id: I3beb3f2ee2f4717b80c5422a2d3db8e93d322a1c
This change fixes a race condition between deleting a subport in the
trunk plugin and the actual deletion in the OVN NBDB.
Change-Id: I836d47a1879d474c2171905416a2838cfe3bab5a
Closes-Bug: #2067400
Commit 260c968118934 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] https://github.com/google/re2/issues/156
Related-bug: #2065821
Change-Id: I3bba89ac14414c6b7d375072ae92d2e0b5497736
As mentioned in the related bug we are seeing
hign memory usage in the job since sqlalchemy
bump to 2.0 and this leads to gate instability.
Adding some swap to handle this until the issue
is fixed.
Also reverts the concurrency reduction change[1]
that was done for this issue as that shouldn't be
needed now.
[1] https://review.opendev.org/c/openstack/neutron/+/920766
Related-Bug: #2065821
Change-Id: I33c4869c1d5230c0c8cc2f0dd4f6d071600bf220
This is to include Ief3ab2f56fa3d805296709e12e5f7a71560f7b6e that is
needed by I730a12746bceaa744c658854e38439420efc4629.
Related-Bug: #2056366
Change-Id: I8a21c96e18df89301e5f1eeab51c4026e2635de9
Zuul has deprecated the usage of negative regex[1] and
reports WARNINGs when these are used.
This patch switches the branches regex to the supported
one.
[1] https://review.opendev.org/c/zuul/zuul/+/916141
Change-Id: I56a286cf33afb574436039128095e260539f63d9
There are three reasons to revert this patch.
1. It broke RPC push API for trunks because it added port db model to
event payload that is not serializeable.
2. It also broke the callback event payload interface, which requires
that all entries in .states attribute belong to the same core object.
To quote from neutron-lib,
```
# an iterable of states for the resource from the newest to the oldest
# for example db states or api request/response
# the actual object type for states will vary depending on event caller
self.states = ...
```
3. There is no good justification why ml2/ovn would not allow this
operation. The rationale for the original patch was to align the
behavior with ml2/ovs, but we don't such parity requirements. The 409
error that can be returned by the API endpoints is backend specific.
To quote api-ref,
```
409 The operation returns this error code for one of these reasons:
A system configuration prevents the operation from succeeding.
```
AFAIU there is nothing that prevents ml2/ovn to create a trunk in this
situation.
This will have to be backported in all supported branches (the original
patch was backported down to Wallaby).
Conflicts:
neutron/services/trunk/drivers/ovn/trunk_driver.py
This reverts commit 833a6d82cd705548130cdac73a88d388f52c7824.
Closes-Bug: #2065707
Related-Bug: #2022059
Change-Id: I067c2f7286b2684b67b4389ca085d06a93f856ce
A recent change in neutron-lib [1] changed the behavior somewhat,
handling the None value explicitly passed as `allocation_pools` the same
way as if the field was not passed at all (meaning, setting pools from
start/end IP addresses for the subnet.)
This new behavior seems reasonable, so instead of reverting to the
original behavior, I'm making the test cases here not check an error
happens when None is passed.
[1] If768ab6a5f92d200841a734087bbc8fba8870dc6
Change-Id: I938ffabe7e74fa129c58dd4786153a0b4f374194
The job can be affected by any patch landed in neutron-lib; the latter
repo doesn't run the job at all though.
We can add the job to neutron-lib check pipeline too (see bug referred
below), but more generally, we shouldn't gate on unreleased libraries.
The job is still extremely useful, but as advisory signal to anticipate
upcoming breakages.
Related-Bug: #2067515
Change-Id: Ia0be288b794b11659a5c98e4bd7c12a97c958926
Add '--concurrency 4' when running coverage job as it
helps work around an OOM killer issue we are seeing in
the gate. It typically only adds between 10 and 30
minutes to job. Can revert once issue is resolved.
Partial-bug: #2065821
Change-Id: I33aea3a3c884877573d4d45c6e07955bb177c766
When neutron API is called to check requirements for the auto_allocate
topology, it needs to return not only 'tenant_id' field but also
'project_id' as that is required for the policy enforcement.
Without this 'project_id' field requirements check was failing for
member and reader users as they got 404 from the Neutron API. And the
reason why Neutron was returning 404 was that it wasn't passing policy
enforcement due to missing project_id field in the 'target' object.
Closes-bug: #2066369
Change-Id: Idf96a82bc6c8cb0b47dfde3baba94b42a8a8beba
This will guarantee that regardless of ovsdbapp version, Chassis_Private
will be deleted. This allows us to wait for a single event (DELETE) and
test the same behavior for all ovsdbapp versions. (Behavior of agent
listing when both Chassis and Chassis_Private records are deleted from
ovn db.)
Depends-On: https://review.opendev.org/c/openstack/requirements/+/920062
Change-Id: I0dfa21a927067afb532d7632f7e05427623327f5
