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
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
neutron.object.base._use_db_facade() is unused according
to codesearch, except for the test cases. Remove it.
TrivialFix
Change-Id: I8f183584bf66bac157694c51769409dba2c79da2
When a virtual port is moved from one port to another port the
PortBindingUpdateVirtualPortsEvent event would only update the binding
host id in the neutron database, while it is also usefull to keep the
information in the OVN database up to date with the host information
Other plugins that connect to the OVN database can then also rely on the
information stored in the OVN DB's
Closes-Bug: #2038413
Change-Id: I59c6c4b2c8b023b9c9c3bab1741d957fa1f738fc
- Python 2 is no longer supported
- setup.py is no longer managed by the global tooling
- Recent pip does not require appropriate order in requirement files
Change-Id: Iaa1aa0022e207cceb26ed45474bc6edfbbec4faa
This is a follow-up patch to handle a missing comment. The except
branch should never catch a ``AttributeError`` exception, only a
``KeyError`` if that is missing in the ``data`` dictionary.
Related-Bug: #2013228
Change-Id: I6a3249649dde58e666048a613640338ea8af7b36
Metering agent don't supports ML2/OVN backend currently and this should
be documented in the feature parity gaps document.
Related-bug: #2048773
Change-Id: I2b8c37f33e3ae4b17cc88bffde014d7d730e59d3
This config option was originally introduced before
the networking-ovn merge into neutron in 2019, and as
there is no usage it can be safely removed.
TrivialFix
Change-Id: I8ac826926dc8d3881ee57dc677f41bdbed00e5c0
