[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