Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1955127

Summary: [RFE][ovn][migration] pre-migration step to arrange VNIs when the target overlay is VXLAN
Product: Red Hat OpenStack Reporter: Daniel Alvarez Sanchez <dalvarez>
Component: python-networking-ovnAssignee: OSP Team <rhos-maint>
Status: CLOSED WONTFIX QA Contact: Eran Kuris <ekuris>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16.1 (Train)CC: apevec, egarciar, jlibosva, lhh, majopela, mtomaska, scohen
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-10-11 19:31:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Daniel Alvarez Sanchez 2021-04-29 13:47:21 UTC 
The VXLAN implementation for ML2/OVN poses a limitation of 4K networks and 4K ports per network. If the user selects VXLAN as the target overlay for the ML2/OVN migration, the migration process should validate that the cloud is suitable before attempting the migration.

If the upgrade qualifies, the tool needs to arrange the VNIs in that way that all of them are < 4K since there could be VNIs beyond that number:

Example:

User creates networks from 1 to 5000 so the VNIs are 1...5000.
Now the user deletes the first 1K networks and the VNIs are 1001...5000.

While the migration to ML2/OVN qualifies (#ports < 4096), the VNI numbers are beyond the limit and they should be re-arranged to fit within the range as a pre-migration step.

The control plane should be fenced as well during this change to avoid a race between the validation and the actual migration.


Please note that there's a potential disruption when changing the VNIs in the dataplane since the nodes that have workloads in a given network need to all honor the change until communication can happen across them.
Comment 3 Red Hat Bugzilla 2024-02-09 04:25:06 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days