[neutron] Switching the ML2 driver in-place from linuxbridge to OVN for an existing Cloud

Christian Rohmann christian.rohmann at inovex.de
Mon Aug 22 20:32:35 UTC 2022


Hello openstack-discuss and neutron experts,

I'd like to ask for your input and discussion on the idea of changing 
the ML2 driver for an existing cloud, read: changing a tire while still 
riding the bike.

I actually like to find out if it's feasible to switch from the trusted 
Linuxbridge driver to the more modern SDN stack of OVN - in place.
With all existing user networks, subnets, security groups and (running) 
instances in the database already.  And while I know there a push of 
migrating
from OVS to OVN and a clear migration path documented 
(https://docs.openstack.org/neutron/latest/ovn/migration.html), but they 
are much more similar in their data plane.

And to get this out of the way: I am not asking to do be able to do this 
without downtime, interruptions, migrations or any active orchestration 
of the process.
I just want to know all the possible options apart from setting up a new 
cloud and asking folks to migrate all of their things over...

1) Are the data models of the user managed resources abstract (enough) 
from the ML2 used?
So would the composition of a router, a network, some subnets, a few 
security group and a few instances in a project just result in a 
different instantiation of packet handling components,
but be otherwise transparent to the user?

2) What could be possible migration strategies?

While it might be a little early to think about the actual migration 
steps. But just to consider more than a full cloud shutdown following a 
cold start with modified neutron config then using the OVN ML2.
I know there is more than just the network and getting a virtual layer 2 
network. There are DHCP, DNS and the metadata service and last but not 
least the gateway / router and the security groups.
But if using VXLAN for OVN (as Linuxbridge uses currently) could the 
shift from one implementation to the other potentially be done node by 
node? Or project by project by changing the network agents over
to nodes already running OVN?

If not, is there any other hot cut-over approach that would avoid having 
to shutdown all the instances, but only cause them some network downtime 
(until the next DHCP renew or similar?)


Has anybody ever done something similar or heard about this being done 
anywhere?



Thanks for your time and input,


Christian





More information about the openstack-discuss mailing list