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
Only create multiple default routes when the router has the
`enable_default_route_ecmp` attribute set to True.
Partial-Bug: #2002687
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: I17512ec494661151e46282f0bd08abc55bef1df8
The general approach is to update the ovn_client and ovn_db_sync
code to handle multiple gateway ports wherever a single gateway
port is handled today.
In this patch set multiple static routes for default gateway will
be added by default when multiple gw ports are present. Support
for the `enable_default_route_ecmp` attribute to control this
behavior will be added in subsequent patch set to avoid making
this change too large.
Partial-Bug: #2002687
Change-Id: I00b1f29172be5a0034b921b11af3a8d502273766
A non-vlan-transparent trunk parent port (tpt) should only forward
untagged frames. Earlier it was configured to forward anything (trunk
mode in ovs). This patch changes the trunk mode to access mode and
sets the trunk parent's tag explicitly to 0.
Change-Id: I4bcfe53fe87d7c9218dd0db9d7224bb323709a21
Closes-Bug: #2048785
All of these exceptions and constants have been in
neutron-lib for a while, start using them.
While looking for other things to consume found an old
neutron-lib TODO that did not apply anymore, so removed.
TrivialFix
Change-Id: I9431075a50ba05be872db422125e6af6266ccb99
The shell command "ovsdb-client", in the functional tests, is prone to
timeouts. This patch adds a tenacity decorator and sets the command
timeout to 3 seconds, that should be more than enough to retrieve one
single register.
Closes-Bug: #1955008
Change-Id: I38626835ca809cc3f2894e5f81fab55cf3f40071
Each OVN agent extension can implement a start method. It is called
after the extension manager initialization, at the end of the
``OVNNeutronAgent.start`` call.
Related-Bug: #2017871
Change-Id: I334027f061fa963c1cf24540b27c1ff76145b977
Now the ``OVNNeutronAgent.load_config`` method is public and accessible
by the OVN agent extensions.
This patch also makes use of the property ``ovs_idl``, that implicitly
loads the OVS IDL if it is not done previously.
Related-Bug: #2017871
Change-Id: I356c16d753b524736673a665a6590ae903be5682
Support is added to the OVN L3 service plugin for the router
flavors and service type framework
Partial-Bug: #2020823
Change-Id: If40d7b39e7b59a39ff7622bd823dbdb14bfc69d2
if a gateway chassis is removed we previously only plugged the hole it
left in the priorities of the lrps. This can lead to bad choice since we
are bound by all other currently used chassis.
By allowing us to also reschedule the lower priorities we get
significantly more freedom in choosing the most appropriate chassis and
prevent overloading an individual one.
As an example from the new testcase:
previously we would have had all prio 2 schedules on chassis3, but with
this change now this distributes better also to chassis4.
Partial-Bug: #2023993
Change-Id: I786ff6c0c4d3403b79819df95f9b1d6ac5e8675f
previously we calculated the "load" of a chassis across the highest
priority of each of the chassis. This can lead to suboptimal results in
the following situation:
* you have gateway chassis: hv1, hv2, hv3
* you have routers:
* g1: with priority 3 on hv1, priority 2 on hv2, priority 1 on hv3
* g2: with priority 3 on hv1, priority 2 on hv2, priority 1 on hv3
* g3: with priority 3 on hv3, priority 2 on hv2, priority 1 on hv1
* g4: with priority 3 on hv3, priority 2 on hv2, priority 1 on hv1
When now creating a new router the previous algorythm would have placed
prio 3 of it either on hv1 or hv3 since their count of highest
priorities (2 of prio 3) is lower than the count of the higest priority
of hv2 (4 of prio 2). So it might have looked like:
* g5: with priority 3 on hv3, priority 2 on hv1, priority 1 on hv3
(This case has been implemented as `test_least_loaded_chassis_per_priority2`).
However this is actually a undesired result. In OVN the gateway chassis
with the highest priority actually hosts the router and processes all of
its external traffic. This means it is highly important that the highest
priority is well balanced.
To do this now we no longer blindly use the count of routers of the
highest priority per chassis, but we only count the routers of the
priority we are currently searching a chassis for. This ensures that in
the above case we would have picked hv2 for priority 3, since it has not
actually active router running.
The algorithm implemented now is based upon the assumption, that amount
of priorities scheduled per router is equal over all routers. This means
it will perform suboptimally if some phyiscal network is available on 5
gateway chassis, while another one is only available on 2. (It is
however unclear if the previous implementation would have been better
there).
In this commit we also adopt the testcases in test_l3_ovn_scheduler to match
to this assumption. Previously the distribution data used for testing
had been unrelasitic as it mostly scheduled one gateway chassis for each
router.
It also fixes the previously broken priority calculation in the
testcase, that would just assign prio 0 to all gateways.
Partial-Bug: #2023993
Change-Id: If2afcd546a1da9964704bcebbfa39d8348e14fe8
If the ``IpLinkCommand.set_netns`` fails, the method restores the
previous device namespace before raising the exception.
Closes-Bug: #2049590
Change-Id: I73b36ef161441b52922d888c11a144eafe8a7ed0
This patch is the initial implementation on the suggestion
from this patch[1].
The DHCP agent can query the existing `get_ports` RPC method because
this method is already exposed in the MetadataRpcCallback(server side)
which runs under the same topic(PLUGIN) and namespace(None). The benefit
here is that there is no change needed to the API, however it does
go against how we historically setup the RPC layer between a server and client.
[1] https://review.opendev.org/c/openstack/neutron/+/903572/comments/3d4e0453_4b4d2ab6
Related-Bug: #1982569
Change-Id: Icd7c55d2a5103bdbd90907b1dbfb9ccfe34c020a
When a router interface is created, the corresponding subnet gateway IP
is tested first [1]. If the subnet has no gateway IP, the router
interface cannot be created. This IP will be assigned to this port.
The Neutron API also prevents from modifying the subnet gateway IP
if assigned to a router interface [2]. However the API is not
preventing the subnet gateway IP deletion. This patch is adding
this check.
This patch is being tested in the neutron-tempest-plugin [3].
[1]de58c1b995/neutron/db/l3_db.py (L902-L904)
[2]de58c1b995/neutron/db/db_base_plugin_v2.py (L715)
[3]https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/904710
Closes-Bug: #2036423
Change-Id: I4c7b399a3a052749abdb88fb50be628ee91b63a0
Same as in ML2/OVS, the ML2/OVN mechanism driver adds to the port
VIF details dictionary the OVS bridge the port is connected to
and the integration bridge datapath type.
Closes-Bug: #2045889
Change-Id: Ifda46c42b9506449a58fbaf312cc71c72d9cf2df
neutron.object.base._use_db_facade() is unused according
to codesearch, except for the test cases. Remove it.
TrivialFix
Change-Id: I8f183584bf66bac157694c51769409dba2c79da2
