[neutron] LXB Removal and OVN migration
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. Any suggestions or recommendations on the best path forward? Also, will the dynamic routing agent work with ovn?
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.... 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. 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> """
Hi Ricardo, We (some operators) are trying to meet (semi-) regularly to exchange problems/experiences like this, next time on March 11 1500 UTC, see: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack....
With the removal of the linuxbridge mechanism driver, has anyone successfully completed an in-place migrationfrom LinuxBridge to OVN?
At CERN, we plan to migrate most users in-place while running LinuxBridge and OVN at the same time (via cold/live migration). That being said, we only have provider network for the users and will go hypervisor by hypervisor. From what I saw in neutron, it looks like you could have LinuxBridge and OVN as providers at the same time. Running both LXB and OVN on the same hypervisor I haven't tried as well as overlay networks, and this is where the tricky part might start depending on the overlay used and potential downtime you want to have for your users. Best, Daniel ________________________________ From: Sean Mooney <smooney@redhat.com> Sent: Monday, March 3, 2025 15:21 To: Ricardo Cano <ledsole@gmail.com>; openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Subject: Re: [neutron] LXB Removal and OVN migration 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.... 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. 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> """
Thanks Daniel, we would be happy to take part in that On Mon, Mar 3, 2025 at 10:41 AM Daniel Failing <daniel.failing@cern.ch> wrote:
Hi Ricardo,
We (some operators) are trying to meet (semi-) regularly to exchange problems/experiences like this, next time on March 11 1500 UTC, see: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack....
With the removal of the linuxbridge mechanism driver, has anyone successfully completed an in-place migrationfrom LinuxBridge to OVN?
At CERN, we plan to migrate most users in-place while running LinuxBridge and OVN at the same time (via cold/live migration). That being said, we only have provider network for the users and will go hypervisor by hypervisor. From what I saw in neutron, it looks like you could have LinuxBridge and OVN as providers at the same time. Running both LXB and OVN on the same hypervisor I haven't tried as well as overlay networks, and this is where the tricky part might start depending on the overlay used and potential downtime you want to have for your users.
Best, Daniel
________________________________ From: Sean Mooney <smooney@redhat.com> Sent: Monday, March 3, 2025 15:21 To: Ricardo Cano <ledsole@gmail.com>; openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Subject: Re: [neutron] LXB Removal and OVN migration
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....
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.
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>
"""
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....
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/1ddcb3e8901b87b914ef6c2819b1674190... 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
Hi Ricardo, please also check a topic *[Neutron][operators] LinuxBridge to OVN Outreach* on mailing list. There is a meeting in next Tuesday about a similar case, so maybe you can raise your questions during the meeting? Best regards, /Jan Wasilewski On Mon, Mar 3, 2025 at 5:08 PM Sławek Kapłoński <skaplons@redhat.com> wrote:
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....
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/1ddcb3e8901b87b914ef6c2819b1674190... 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
Hi Sean, I just wanted to respond with my own opinions on things here, comments below. On 3/3/25 9:21 AM, Sean Mooney wrote:
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
When we changed the name from Quantum to Neutron (2013), the default backend in devstack was changed to Openvswitch. In 2021 the default was changed to OVN (twice if you count the revert/resubmit). We agreed at the time OVN was the recommended architecture going forward and have kept moving in that direction since then. There are less core reviewers and we can only support a limited number of things, so there will be these "burn the ships" moments in our future I can imagine.
in the install guide since it creation until it was marked experimental by neutron
We have been notoriously slow at updating the in-tree install guides, but we changed it in 2023.1 to Openvswitch since it was a simple fix. We'll update it again, but they are generally not widely used by anyone doing an enterprise install.
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....
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.
I would disagree. Both the Red Hat and Ubuntu installers have defaulted to OVN since Yoga (or before), and afaik only support OVN from 2024.1 onward. I have never seen a customer deployment using Linuxbridge, and have only seen 2 using ML2/OVS (and it was the same customer). There was a recent question on the list about an OVN install failure that showed some issues in the docs, the sender is submitting a bug and working on an update based on their experience. I am glad the operator community picked-up the work of helping with the transition to OVN, and our goal now is to make sure we can help with any issues that arise, either in the docs or code, to make that successful. -Brian
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.
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>
"""
On 03/03/2025 21:28, Brian Haley wrote:
Hi Sean,
I just wanted to respond with my own opinions on things here, comments below.
On 3/3/25 9:21 AM, Sean Mooney wrote:
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
When we changed the name from Quantum to Neutron (2013), the default backend in devstack was changed to Openvswitch.
that was never actully change in the docs. the docs always presented libivrt first and presented ovs as the alternative and then later ovn. taking train as an example https://docs.openstack.org/neutron/train/install/controller-install-ubuntu.h... you can see its documenting "service neutron-linuxbridge-agent restart" so even though we as developer knew that ovs was the de-facto default it not what we communicated to users and operators via our docs.
In 2021 the default was changed to OVN (twice if you count the revert/resubmit). We agreed at the time OVN was the recommended architecture going forward and have kept moving in that direction since then. There are less core reviewers and we can only support a limited number of things, so there will be these "burn the ships" moments in our future I can imagine.
its kind of a shame because the ml2/ovs plugin is still more feature rich and easier to debug then ovn. i understand the reviewer/maintainer problem, but i don't think we are at a point where ml2/ovs could realistically be deprecated for example any time soon.
in the install guide since it creation until it was marked experimental by neutron
We have been notoriously slow at updating the in-tree install guides, but we changed it in 2023.1 to Openvswitch since it was a simple fix. We'll update it again, but they are generally not widely used by anyone doing an enterprise install.
that may be but its the only place we document our default/recomemnted backend as far as im aware. does neutron have some other offical docuemtn where you document this policy. we do not use config in code to provide a default ml2 driver https://docs.openstack.org/neutron/latest/configuration/ml2-conf.html#ml2.me... so the install guide is really the only official document that an installer writer or operator can use to inform there decisions on the recommend backend.
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....
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.
I would disagree. Both the Red Hat and Ubuntu installers have defaulted to OVN since Yoga (or before), and afaik only support OVN from 2024.1 onward. I have never seen a customer deployment using Linuxbridge, and have only seen 2 using ML2/OVS (and it was the same customer).
you are conflating two diffenet things here. there are downstream product decisions and upstream community support. kolla to this day defaults to ml2/ovs, openstack ansible uses to default to linux bridge. devstack has migrated form linxubirdge to ovs to ovn over the years. those are installer default not default of the project. redhat installer made non default changes to nova config option too but we do not consider those to be project default of nova. most of those we conditioner to be tripleo bugs... but the defaults of an installer are the domain of the installer team.
There was a recent question on the list about an OVN install failure that showed some issues in the docs, the sender is submitting a bug and working on an update based on their experience.
I am glad the operator community picked-up the work of helping with the transition to OVN, and our goal now is to make sure we can help with any issues that arise, either in the docs or code, to make that successful.
form a nova perspective ovn is still not a well behaved backend as it does not properly follow the contract about when network-vif-plugged events are sent. we have been working around quirks/defects in that integration for years i agree that many of the original gaps https://docs.openstack.org/neutron/latest/ovn/gaps.html have now been addressed.
-Brian
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.
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>
"""
On Mar 3, 2025, at 8:50 AM, Ricardo Cano <ledsole@gmail.com> 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.
Any suggestions or recommendations on the best path forward?
Also, will the dynamic routing agent work with ovn?
Hi Ricardo, for the dynamic routing with OVN you can check the ovn-bgp-agent project [1] and see if it would fit your needs. Note that it does not use any API from the Neutron dynamic routing. Jakub [1] https://opendev.org/openstack/ovn-bgp-agent
participants (7)
-
Brian Haley
-
Daniel Failing
-
Jakub Libosvar
-
Jan Wasilewski
-
Ricardo Cano
-
Sean Mooney
-
Sławek Kapłoński