OpenStack Ops Radio Hour - March 27, 2026

Why It Matters

Adopting OVN reshapes OpenStack networking by improving scalability and reducing messaging overhead, but successful migration demands careful planning, clustering, and performance tuning to maintain service reliability.

Key Takeaways

• CERN migrating from Linux Bridge to OVN shares blog resources
• Operators report OVN reduces RabbitMQ load and improves scalability
• Migration tool requires stopping Neutron, cleaning OVS flows, reconfiguring ML2
• OVNDB clustering essential to avoid single‑point‑of‑failure concerns in production
• Packet drops may occur at hypervisor ingress without DPDK optimization

Summary

The OpenStack Ops Radio Hour on March 27, 2026 centered on a community‑driven deep‑dive into Open Virtual Network (OVN) as the default software‑defined networking layer for OpenStack. Participants from CERN, CSC Finland, a Brazilian university, and other operators exchanged real‑world migration experiences, highlighting resources such as CERN’s blog posts and an open‑source migration tool hosted on GitHub.

Key insights emerged around the practical steps of moving from Linux Bridge or OVS to OVN: stopping Neutron services, purging existing OVS flows, cleaning namespaces, and updating the ML2 configuration to point to the OVN north‑ and south‑bound databases. Operators reported that OVN eliminated the need for a heavyweight RabbitMQ messaging layer, delivering smoother scaling across 500 hypervisors and thousands of VMs. However, concerns about a single‑node OVN north‑bound database prompted many to deploy a three‑node OVNDB cluster for resilience.

Notable examples included Eduardo’s detailed migration walkthrough, which cited a 10‑50‑minute data‑plane downtime on test clusters and highlighted a lingering issue with the Neutron provider_associations table. CERN’s team praised the performance gains but noted occasional bugs causing misrouted traffic. The discussion also touched on packet‑drop hotspots at hypervisor ingress, suggesting DPDK‑based OVS as a potential mitigation for high‑throughput workloads.

The implications are clear: operators planning OVN adoption must allocate time for learning the new control plane, ensure OVNDB clustering, and evaluate performance‑tuning options like DPDK. Community‑generated documentation and tooling can accelerate migration, but thorough testing—especially with services like Octavia—is essential to avoid unexpected downtime.

Original Description

This is the recording of the monthly OpenStack Ops Radio Hour gathering on Meetpad (OpenDev's Jitsi). The etherpad for the discussion is: https://etherpad.opendev.org/p/openstack_ops_radiohour