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
There are a few warnings disabled that do not generate
failures any more, re-enable them by removing from
.pylintrc file.
TrivialFix
Change-Id: I1a4fff33b0dcd3d88b4ab0c86546098c7a9cafa4
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
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
We recently met an issue during VM live migration:
1. nova starts live migration
2. plug ports on new host
3. neutron-ovs-agent starts to process the port,
but the port is in 'added' and 'updated' set
at the same time.
4. because nova still not activate the destination
port binding, so there is no local vlan for
this port.
Then, ovs-agent met errors:
Error while processing VIF ports: OVSFWTagNotFound:
Cannot get tag for port tap092f38ed-a7 from its other_config: {}
This fix is to remove ports of the
"binding_no_activated_devices" for ``setup_port_filters``.
Closes-Bug: #2048979
Change-Id: I0f1e6bf202ef08f75246d6e99b3774d0b6fc9e2b
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
This deprecated name for quota_rbac_policy was
introduced before 2016, and as there is no usage
according to codesearch it can be safely removed.
TrivialFix
Change-Id: I5cc3392985ee595999a5030e6b9c80a4c3009187