api_workers=0 does not disable api workers but neutron-server still
launches one api worker. Rejecting 0 helps user notice that the value
they request in config files is not honored.
Also the other rpc workers options disable the corresponding workers
completely by setting these options to 0, so setting negative values
work but does not bring any special benefit.
Change-Id: Iac16b241c71ac1068c6fbea3cc792b74bfc66c03
Currently at least 1 rpc worker is launched even when a user requests
zero workers by setting rpc_workers=0. The setting of rpc_workers=0 is
used when ml2-ovn plugin is used without any additional agent, and in
this deployment pattern the single rpc worker is not at all used.
This change ensures no rpc worker is launched when rpc_workers options
is explicitly set to 0. This may be classified as a breaking change,
but is consistent with the earlier change[1] for rpc_workers=0.
[1] 3e1e2d63b3383d28c9a36b00000ab89caffa3829
Closes-Bug: #2052484
Change-Id: I878e50c3192ecd3b145ded0ab8394845a089696e
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
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
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
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
Prior to this patch, ML2/OVS and ML2/OVN had inconsistent IGMP
configurations. Neutron only exposed one configuration option for IGMP:
igmp_snooping_enabled.
Other features such as IGMP flood, IGMP flood reports and IGMP flood
unregistered were hardcoded differently on each driver (see LP#2044272
for a more details).
These hardcoded values has led to many changes over the years tweaking
them to work on different scenarios but they were never final because
the fix for one case would break the other.
This patch introduces 3 new configuration options for these other IGMP
features that can be enabled or disabled on both backends. Operators
can now fine tune their deployments in the way that will work for them.
As a consequence of the hardcoded values for each driver we had to break
some defaults and, in the case of ML2/OVS, if operators want to keep
things as they were before this patch they will need to enable the new
mcast_flood and mcast_flood_unregistered configuration options.
That said, the for ML2/OVS there was also an inconsistency with the help
string of igmp_snooping_enabled configuration option as it mentioned
that enabling snooping would disable flooding to unregistered ports but
that was not true anymore after the fix [0].
[0] https://bugs.launchpad.net/neutron/+bug/1884723
Closes-Bug: #2044272
Change-Id: Ic4dde46aa0ea2b03362329c87341c83b24d32176
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
This patch adds support for IPv6 metadata service in ML2/OVN.
The changes include:
- Add the 'fe80::a9fe:a9fe/128' address to the interface of the
ovnmeta- namespace so that it's reachable from the guests
- Identify the port of the VM by looking up the source MAC address
of the metadata request
- Restarts the haproxy instances to honor the configuration changes
upon start of the metadata agent. In particular, haproxy now also
binds on the 'fe80::a9fe:a9fe' address
When the VM requests metadata from its LLA, the traffic will reach
the ovnmeta namespace associated to its network.
The IPv6 metadata tests are passing and enabled in Tempest by
this patch:
https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/894027
Besides, this patch ensures that the link-local address of the
metadata interface is present so that the metadata IPv6 endpoint
is reachable. It also fixes a bug that was causing the wrong LLA
to be present as the interface was set `up` first prior to changing
the MAC address. Now this order is inverted so that the proper LLA
is configured.
Change-Id: Idcef6de33ed2a73cb3c426db1c55fa9cd06de63f
Signed-off-by: Daniel Alvarez Sanchez <dalvarez@redhat.com>
This patch removes the compatibility with OVN under v20.09. That
implies the OVN Southbound definition has "Chassis_Private" table.
Any previous check is removed from the code.
This patch also adds a sanity check, testing that the OVN Southbound
database definition is greater or equal to 2.9.0 [1].
The testing OVN NB and SB schemas are updated to the files contained in
OVN v22.09. The new testing NB schema version is 6.3.9; the new testing
SB schema version is 20.25.0.
[1]4adc10f581
Closes-Bug: #2002839
Change-Id: Iec8854749a1df81eb6a7154d3f951e176c69156d
Support for the required DHCPv6 options was recently added in core
OVN with [1].
This patch adds support for that in ML2/OVN backend also and by that
closing one of the gaps between ML2/OVN and ML2/OVS backends.
This patch also adds upgrade check to check used ovn version and warn
operators if native OVN DHCP is used for BM provisioning and OVN version
is older than 23.06.0.
Unfortunately there is no easy way to check used version of OVN so check
relies on the ovnnb schema version.
[1] c5fd51bd15
Closes-Bug: #2030520
Change-Id: Iaa3ff8e97021e44f352e5a9a370714bf5f1d77b8
This option has been marked deprecated since Ussuri
as it is a duplicate of OVS:integration_bridge, let's
remove it.
TrivialFix
Change-Id: I81bc5f3d98f752d926a243cbd17b8b894f2bdf58
The network_subnet_mtu_validation release note was
accidentally put in the wrong subdirectory, move it
to the correct location.
As this merged in 2023.2 we should backport to there
as well.
TrivialFix
Change-Id: I3175c0f5179aa87422cf779b7568903cc903a669
The segment_mtu option was replaced with global_physnet_mtu
back in Mitaka, let's remove it as it's unused anywhere.
TrivialFix
Change-Id: Ib6e3ff7da700c2b312c7071734d0a5d498238eff
OVN added support for aging out MAC_Binding entries [1][2].
Without this feature, the MAC_Bindings table can grow indefinitely.
[1] 1a947dd307
[2] cecac71c0e
Closes-Bug: 2033932
Change-Id: I91070ad6addb30ffdedba5d561984d2f6626e2b7
When syncing hostname and physical networks, filter neutron
hosts on agent_type. Only segmenthostmappings for hosts
with agent 'OVN Controller agent' should be cleaned up.
Since change: I935186b6ee95f0cae8dc05869d9742c8fb3353c3 there
is de-duplication of segmenthostmapping updates from agents.
If the OVN DB sync clears/deletes mappings for hosts owned by
other agents/plugins the mappings are never re-created.
Closes-Bug: #2040172
Change-Id: Iaf15e560e1b1ec31618b2ebc6206a938463c1094
Signed-off-by: Harald Jensås <hjensas@redhat.com>
The OVN changed support for NAT rules including a new column and auto discovery logic (which may not work in some cases) [1][2].
If the OVN backend supports this column in the Northbound DB Schema, set gateway port uuid to any floating IP to prevent North/South traffic issues for floating IPs.
This patch updates the method for creating FIP NAT rules in OVN backend and updates previously created FIP rules to include the gateway_port reference. This NAT rule update task runs only once during the maintenance task, and if all entries are already configured no action is performed.
[1] 15348b7b80
[2] 2d942be7db
Closes-Bug: 2035281
Change-Id: I802b6bd8c281cb6dacdee2e9c15285f069d4e04c
The vnic type should not be changed once the port is bound since it's
related to the actual port binding. The patch validates the port update
operation and fails the update if the vnic type is attempted to be
changed on a bound port.
Closes-bug: #2033090
Change-Id: I5cb79d9da96ba41a7787083c81f522c328fae049
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
This patch introduces a new configuration for OVN CMS Options called
"enable-chassis-as-extport-host". This configuration can be used
by ML2/OVN to identify nodes that are eligible for scheduling OVN's
external ports.
Prior to this patch, external ports were always scheduled on centralized
networked nodes tagged with the "enable-chassis-as-gw" flag in the OVN
CMS Options but, when it comes to deploying OpenStack on OpenShift
requiring services such as the OVN Metadata Agent or DHCP Agent to
serve those external ports and running them on control plane nodes are
not ideal. This is where this patch comes handy allowing these ports to
have more flexibility in where they are scheduled.
The patch is also backward compatible and if the new configuration is
not present on the OVN CMS Options, ML2/OVN will continue to schedule
the external ports on nodes configured with the previous configuration
like always.
Documentation will be updated on a follow up patch.
Closes-Bug: 2037294
Change-Id: Ic46d847e3aebfe543d5a7ab49d18d1f1abf1342e
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
These were deprecated during Xena cycle[1], so can be removed now.
[1] adfd853267ca529816f4c17a145d9e70e8abfac5
Related-Bug: #1927494
Change-Id: I9fadaa6cfcd66409da47422505c145d9d67f6b8c
In [1] we added support for FDB learning. In order to avoid issues
due to that table increasing without limits, which will impact OVN
performance, this patch is adding support for its aging mechanisms
which was added in OVN 23.09 in [2]. By default is disabled, so if
`localnet_learn_fdb` is enabled, the new configuration parameters
should be appropriately configured too: `fdb_age_threshold` and
`fdb_removal_limit`
[1] https://review.opendev.org/c/openstack/neutron/+/877675
[2] ae9a548882
Closes-Bug: 2035325
Change-Id: Ifdfaec35cc6b52040487a2b5ee08aba9282fc68b