Hi,

Dnia poniedziałek, 3 marca 2025 15:21:18 czas środkowoeuropejski standardowy Sean Mooney pisze:
>
> On 03/03/2025 13:50, Ricardo Cano wrote:
> > Hello openstack-discuss,
> >
> > With the removal of the linuxbridge mechanism driver, has anyone
> > successfully completed an in-place migrationfrom LinuxBridge to OVN?
> > I did come across this
> > https://www.jimmdenton.com/migrating-lxb-to-ovn/ and that looks good
> > as a one-shoit while biting the bullet and taking a full outage.
> > However, I was wondering if it was possible to run lxb and ovn
> > side-by-side and cut them over, say one network at a time.
> >
> > This particular deployment was stood up using openstack-ansible back
> > in the rocky days (now running antelope) and it appears that openstack
> > ansible's default was lxb up until Zed.
>
> that is likely because the official default backend of neutron was Linux
> bridge
>
> in the install guide since it creation until it was marked experimental
> by neutron
>
> our devstack ci jobs defaulted to ovs for most of openstack lifetime but
>
> ovs only became the offical default backend when linux bridge was marked
> experimental
>
> https://docs.openstack.org/neutron/latest/install/controller-install-ubuntu.html#finalize-installation
>
> ovn is still not the default in the docs or in most installers even if
> that is what we use in the devstack jobs
> by default.
>
> its an add on alretrnive procedure for "advanced users only"
>
> https://docs.openstack.org/neutron/latest/install/ovn/manual_install.html
>
> so openstack-ansibel was jsut followign the documented defautl backend.
>
> kolla, devstack and tripleo diverged from that.
>
> >
> > Any suggestions or recommendations on the best path forward?
> >
> > Also, will the dynamic routing agent work with ovn
>
> i believe ovn does DVR differently without a requirement form the agent.
>
> i.e. if the vm has a floating ip i belive ovn can route that traffic
> locally to the internet form the compute without
>
> needing to use a central gateway but ill admit i could be missremebering
> that i have not looked at it in detail in a number of years.

There is config option for that. It is called `enable_distributed_floating_ip`: https://github.com/openstack/neutron/blob/1ddcb3e8901b87b914ef6c2819b1674190f067d7/neutron/conf/plugins/ml2/drivers/ovn/ovn_conf.py#L130 and it is set to False by default (which is strange, I was always sure it is enabled by default)
So with this setting set to `False` traffic will always go through the gateway chassis but if you will set it to `True`, floating IPs traffic will be distributed.
Please remember that SNAT traffic for the instances which don't have Floating IP associated it is always centralized.

>
> https://docs.openstack.org/neutron/latest/ovn/gaps.html
>
> """
>
>   *
>
>     Floating IP Port Forwarding in provider networks and with
>     distributed routing
>
>     Currently, when provider network types like |vlan| or |flat| are
>     plugged to a router as internal networks while the
>     |enable_distributed_floating_ip| configuration option is enabled,
>     Floating IP port forwardings which are using such router will not
>     work properly. Due to an incompatible setting of the router to make
>     traffic in the vlan/flat networks to be distributed but port
>     forwardings are always centralized in ML2/OVN backend. This is being
>     reported in [11]
>     <https://docs.openstack.org/neutron/latest/ovn/gaps.html#id23>.
>
> [11] https://bugs.launchpad.net/neutron/+bug/2028846
> <https://bugs.launchpad.net/neutron/+bug/2028846>
>
> """
>
> >
>
>


--
Slawek Kaplonski
Principal Software Engineer
Red Hat