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
These are detected as errors since the clean up was done[1] in
the requirements repository.
[1] 314734e938f107cbd5ebcc7af4d9167c11347406
Change-Id: I619d4663cc4a46729c6e169b85071f27bb73e993
If enable explicitly_egress_direct=True and set port as
no security group and port_security=False, the ingress
flood will reappear. The pipleline is:
Ingress
table_0 -> table_60 -> NORMAL -> VM
Egress
table_0 -> ... -> table_94 -> output
Because ingress final action is normal, the br-int will learn the
source MAC, but egress final action is output. So VM's mac will
never be learnt by the br-int. Then ingress flood comes again.
This patch adds a default direct flow to table 94 during the
openflow security group init and explicitly_egress_direct=True, then
the pipleline will be:
Ingress
table_0 -> table_60 -> table_94 -> output VM
Egress
table_0 -> ... -> table_94 -> output
And this patch adds the flows coming from patch port which will
match local vlan then go to table 94 do the same direct actions.
Above flood issue will be addressed by these flows.
Closes-Bug: #2051351
Change-Id: Ia61784174ee610b338f26660b2954330abc131a1
A database option has been added to neutron.conf.
Removed the old options rabbit_host and rabbit_password in neutron.conf.
Removed outdated options use_neutron and firewall_driver from linuxbridge_conf.ini.
The admin_ option used in the neutron part of linuxbridge_conf.ini has been updated to the latest.
Modify tenant_name to project_name in the neutron part of linuxbridge_conf.ini
Closes-Bug: #2042647
Change-Id: I3f4538e1e63fb316425ef7c6ab5c53a0a74f739f
In this change, we add the ability to create high availability
user defined router flavors under the ML2/OVN L3 service
plugin.
Closes-Bug: #2020823
Change-Id: I0d26f672d6239d840d3cf817a2553a06ef00a854
This patch updates the list of the Neutron stadium
projects lieutenants and the list of the bugs' contact
person(s).
In detail this patch:
- sets Slawek Kaplonski as contact for RBAC issues
- sets Fernando Royo as contact for 'ovn-octavia-provider' issues,
removing Flavio and myself
- adds new 'ovn-bgp-agent' item with Luis Tomas Bolivar and
Lucas Alvares Gomes as contacts
Change-Id: Iaf344ee30a3500c18ae7facd9010d75af39e995f
Add an item to the instructions on iptables to OVS
firewall migration that the admin should cleanup
any stale iptables rules after completion. It is
out of scope of our documents on how exactly an
adminstrator might do that.
Closes-bug: #1864374
Change-Id: Ie1bf6b82e57a00f61640a131a29d897a9cde4629
While not intended to be perfect, at least tried to update
package names accordingly and remove cruft.
Trivialfix
Closes-bug: #1996241
Change-Id: I0d621faf577ca21488e150b77ce850d02a65823a
This artifact is no longer used in the "Logical_Router" registers (in
the "options" field) to mark this "Logical_Router" as unhosted. A
"Logical_Router" is considered as unhosted if the gateway
"Logical_Router_Ports" have no "chassis" set.
This artifact is also used to create a "Gateway_Chassis" register
pointing to a inexisting invalid chassis called
"neutron-ovn-invalid-chassis". Any "Logical_Router_Port" not bound
to a chassis will have no value in "gateway_chassis" (NOTE1).
NOTE1: this is valid now with the current two OVN L3 schedulers that
use "gateway_chassis" to schedule the "Logical_Router_Port" of a
router. In a future, we can consider using "ha_chassis_group" for
scheduling.
Partial-Bug: #2052821
Related-Bug: #2019217
Change-Id: I12717936fe2bc188545309bacb8a260981f14c88
Document the ``OVNGatewayLeastLoadedScheduler`` behavior when
there are multiple gateway ports.
Partial-Bug: #2002687
Change-Id: I99cf269e35619a2e1fb680d8decbc613267ca62e
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
The DNS ordering and OVN DHCP documents were out-of-date
and using the old neutronclient, updated.
Noticed while fixing an openstackclient bug related to
dns_nameservers ordering.
TrivialFix
Related-bug: #2053201
Change-Id: Iab15750a4adc8dc78d839f0a1b952f9d87bdab8a
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
This patch adds info about the fact that FIP PFs aren't working when
in the ML2/OVN backend distributed routing is enabled and provider
networks are added to the router as internal networks.
Related-Bug: #2028846
Change-Id: I3a0ab43c52a3090257a1accaee00f33abff54e74
This new section describes how the OVN L3 schedulers distribute
the ``Chassis`` candidate list among the Available Zones, in
order to provide more resilience to the L3 HA: if the active
LRP binding fails, the next in the list will belong to another
AZ.
Related-Bug: #2030741
Change-Id: I20aaeefb33c424dc1a9c13f94f2912d0fa973166
This new document adds:
* A definition of the OVN L3 scheduler
* A description of the different OVN L3 schedulers
* How the LRP are re-scheduled if the gateway chassis list
changes.
Related-Bug: #2023993
Change-Id: Idcc0e34227e47df53a1f395c8fd163723d54b933
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
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
Do not allow the subnet cidr of :: to be used when
creating a subnet, except in the case IPv6 prefix
delegation has been specified in the request.
Closes-bug: #2028159
Change-Id: I480e9a117513996f3c070acd4ba39c2b9fe9c0f1
Current translation no longer use babel[1] or these setup.cfg
entries[2].
[1] 4e907ed2f39329eaa12d1712d49ca8903db15124
[2] 22df2f6395c1426485a7cb97166601823f8a2a28
Change-Id: Ic866a41b00c37c549a83274e33ac18d0aba846bb
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>
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
