There's a "gaps" document here: https://docs.openstack.org/neutron/latest/ovn/gaps.html that contrasts ml2/ovn against ml2/ovs. Though it's probably not exactly a matrix but may give some idea. (Note: ml2/ovn is not just "gaps"; it also brings new features, though these are not listed on the "gaps" page, since it was not the goal of the page to put light on benefits of the driver.) On Tue, Jan 14, 2025 at 4:20 PM Karl Kloppenborg < kkloppenborg@resetdata.com.au> wrote:

Yep, end of an era.

However, this spells good news as we focus down on OVN.

Out of curiosity, I couldn’t see a feature matrix for OVN support like that of cinder drivers matrix.

Do we have one stashed somewhere in the documentation?

Thanks, Karl.

Karl Kloppenborg

Chief Technology Officer

m: *+61 437 239 565* *resetdata.com <https://resetdata.com/>*

[image: reset.png]

*ResetData supports Mandatory Client Related Financial Disclosures – Scope 3 Emissions Reporting*For more information on the phasing of these requirements for business please visit; *https://treasury.gov.au/sites/default/files/2024-01/c2024-466491-policy-stat... <https://treasury.gov.au/sites/default/files/2024-01/c2024-466491-policy-state.pdf>*

This email transmission is intended only for the addressee / person responsible for delivery of the message to such person and may contain confidential or privileged information. Confidentiality and legal privilege are not waived or lost by reason of mistaken delivery to you, nor may you use, review, disclose, disseminate or copy any information contained in or attached to it. Whilst this email has been checked for viruses, the sender does not warrant that any attachments are free from viruses or other defects. You assume all liability for any loss, damage or other consequences which may arise from opening or using the attachments. If you received this e-mail in error please delete it and any attachments and kindly notify us by immediately sending an email to *contact@resetdata.com.au <contact@resetdata.com.au>*

*From: *James Denton <james.denton@rackspace.com> *Date: *Wednesday, 15 January 2025 at 7:09 am *To: *Brian Haley <haleyb.dev@gmail.com>, openstack-discuss@lists.openstack.org < openstack-discuss@lists.openstack.org> *Subject: *Re: [neutron][upgrades] Linuxbridge driver removal and migration

You don't often get email from james.denton@rackspace.com. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>

I’ll “pour one out” for our friend, LinuxBridge. It served us well for many, many, years - but the future looks much brighter with OVN!

Thanks for the heads up!

--

James Denton

Principal Architect

Rackspace Private Cloud - OpenStack

james.denton@rackspace.com

*From: *Brian Haley <haleyb.dev@gmail.com> *Date: *Tuesday, January 14, 2025 at 1:40 PM *To: *openstack-discuss@lists.openstack.org < openstack-discuss@lists.openstack.org> *Subject: *[neutron][upgrades] Linuxbridge driver removal and migration

CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!

Hi Stackers,

In 2022, during the Zed cycle, the Neutron team took a step at marking some items as experimental. One of those was the Linuxbridge driver. The reason was due to it being unmaintained for a number of cycles, and no one was able to take on its ownership. The implication of this decision was that it was consider deprecated, even if not given an official warning message.

In doing this, all gate jobs were moved into the experimental queue, feature-parity with other drivers was deemed unnecessary, and bug fixing was considered best-effort. Since then, both major distros have stopped supporting new deployments using Linuxbridge, and have been mainly focused on OVN.

So what does this mean? We (the neutron cores) have come to the conclusion that it is time to take the next step and remove the code from the tree [1]. After 5 cycles of being considered experimental without any investment it just makes sense. We plan on doing this in the current Epoxy cycle.

We realize that there are still deployments using Linuxbridge, and hopefully they have been looking at migration strategies since we originally marked the code experimental. This email is another push to the user community to start looking at this, especially if you are planning any new deployments. There has been at least one migration guide written at [2] (thanks Jim!), and at this point I would encourage those still using Linuxbridge to look at it and start asking any questions they have so we have the chance to make it better and can make that process easier.

Thanks for reading,

-Brian, Neutron PTL

[0] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.opendev.org%2Fc%2Fopenstack%2Fneutron%2F%2B%2F845181&data=05%7C02%7Cjames.denton%40rackspace.com%7C6b4a0414dd644beebe7008dd34d35711%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C638724804492149410%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iMcDJmj2HAtgPtVXvX%2Fr3h%2BhT9ksobJGAKoblCnJI8Q%3D&reserved=0 <https://review.opendev.org/c/openstack/neutron/+/845181> [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.opendev.org%2Fc%2Fopenstack%2Fneutron%2F%2B%2F927216&data=05%7C02%7Cjames.denton%40rackspace.com%7C6b4a0414dd644beebe7008dd34d35711%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C638724804496789930%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=enekNidXn82OGnyBFDcrqMSOxNPzbZFIzDCo22WWEUw%3D&reserved=0 <https://review.opendev.org/c/openstack/neutron/+/927216> [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jimmdenton.com%2Fmigrating-lxb-to-ovn%2F&data=05%7C02%7Cjames.denton%40rackspace.com%7C6b4a0414dd644beebe7008dd34d35711%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C638724804496808486%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iP4PnCPlnSHC1%2FO6XHMKVgVflse1rP4jt0X%2BcCjTI7A%3D&reserved=0 <https://www.jimmdenton.com/migrating-lxb-to-ovn/>

I think the best way to go about this would be if someone cares enough to maintain it for them to create networking-linuxbridge in the same way that networking-ovn existed before and they can continue to maintain it there (possibly under the x namespace). This will remove the burden of continuing to maintain it and those who want to continue to run and maintain it can do it there. ________________________________ From: Nick Jones <nick@dischord.org> Sent: January 16, 2025 4:04 PM To: Brian Haley <haleyb.dev@gmail.com> Cc: openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Subject: Re: [neutron][upgrades] Linuxbridge driver removal and migration You don't often get email from nick@dischord.org. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Playing devil's advocate slightly, and as an operator who has had one eye on migration (with no good answers really since it's quite a jump - although I appreciate the efforts that have gone in to showing that it can be done in principal), what would be entailed to reinstate the LinuxBridge driver? It's been rock solid in my case, and its simplicity is really appreciated. -- -Nick On 14 Jan 2025 at 19:40:26, Brian Haley <haleyb.dev@gmail.com<mailto:haleyb.dev@gmail.com>> wrote: Hi Stackers, In 2022, during the Zed cycle, the Neutron team took a step at marking some items as experimental. One of those was the Linuxbridge driver. The reason was due to it being unmaintained for a number of cycles, and no one was able to take on its ownership. The implication of this decision was that it was consider deprecated, even if not given an official warning message. In doing this, all gate jobs were moved into the experimental queue, feature-parity with other drivers was deemed unnecessary, and bug fixing was considered best-effort. Since then, both major distros have stopped supporting new deployments using Linuxbridge, and have been mainly focused on OVN. So what does this mean? We (the neutron cores) have come to the conclusion that it is time to take the next step and remove the code from the tree [1]. After 5 cycles of being considered experimental without any investment it just makes sense. We plan on doing this in the current Epoxy cycle. We realize that there are still deployments using Linuxbridge, and hopefully they have been looking at migration strategies since we originally marked the code experimental. This email is another push to the user community to start looking at this, especially if you are planning any new deployments. There has been at least one migration guide written at [2] (thanks Jim!), and at this point I would encourage those still using Linuxbridge to look at it and start asking any questions they have so we have the chance to make it better and can make that process easier. Thanks for reading, -Brian, Neutron PTL [0] https://review.opendev.org/c/openstack/neutron/+/845181 [1] https://review.opendev.org/c/openstack/neutron/+/927216 [2] https://www.jimmdenton.com/migrating-lxb-to-ovn/

From what I can recall, the biggest hassle at the moment with the linuxbridge driver - is that it does rely on the eventlet library. There's a proposed community goal to replace eventlet [1] , though the replacement process is time consuming and not really straightforward. So no active contributors to are ready to takeover this migration process. While it could be not the only reason, it's one I heard as close to be one of the most problematic ones during some discussion. But I'd prefer giving the word to Neutron team here, as they obviously have better overview here. And yes, moving the plugin to a separate repo is always an option, and it can be maintained by a different subset of people, while most of the content being copied over from existing one. [1] https://governance.openstack.org/tc/goals/proposed/remove-eventlet.html On Thu, 16 Jan 2025, 22:26 Nick Jones, <nick@dischord.org> wrote:

Thanks Mohammed. I'm super out of the loop on governance, structure etc. so what would that look like in practice - would that give us a plugin that could be referenced, and it'd be maintained with its own set of tests etc., presumably copied over / out from the existing Neutron codebase?

--

-Nick

On 16 Jan 2025 at 21:08:48, Mohammed Naser <mnaser@vexxhost.com> wrote:

...

I think the best way to go about this would be if someone cares enough to maintain it for them to create networking-linuxbridge in the same way that networking-ovn existed before and they can continue to maintain it there (possibly under the x namespace).

This will remove the burden of continuing to maintain it and those who want to continue to run and maintain it can do it there.

------------------------------ *From:* Nick Jones <nick@dischord.org> *Sent:* January 16, 2025 4:04 PM *To:* Brian Haley <haleyb.dev@gmail.com> *Cc:* openstack-discuss@lists.openstack.org < openstack-discuss@lists.openstack.org> *Subject:* Re: [neutron][upgrades] Linuxbridge driver removal and migration

You don't often get email from nick@dischord.org. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification> Playing devil's advocate slightly, and as an operator who has had one eye on migration (with no good answers really since it's quite a jump - although I appreciate the efforts that have gone in to showing that it can be done in principal), what would be entailed to reinstate the LinuxBridge driver? It's been rock solid in my case, and its simplicity is really appreciated.

--

-Nick

On 14 Jan 2025 at 19:40:26, Brian Haley <haleyb.dev@gmail.com> wrote:

Hi Stackers,

In 2022, during the Zed cycle, the Neutron team took a step at marking some items as experimental. One of those was the Linuxbridge driver. The reason was due to it being unmaintained for a number of cycles, and no one was able to take on its ownership. The implication of this decision was that it was consider deprecated, even if not given an official warning message.

In doing this, all gate jobs were moved into the experimental queue, feature-parity with other drivers was deemed unnecessary, and bug fixing was considered best-effort. Since then, both major distros have stopped supporting new deployments using Linuxbridge, and have been mainly focused on OVN.

So what does this mean? We (the neutron cores) have come to the conclusion that it is time to take the next step and remove the code from the tree [1]. After 5 cycles of being considered experimental without any investment it just makes sense. We plan on doing this in the current Epoxy cycle.

We realize that there are still deployments using Linuxbridge, and hopefully they have been looking at migration strategies since we originally marked the code experimental. This email is another push to the user community to start looking at this, especially if you are planning any new deployments. There has been at least one migration guide written at [2] (thanks Jim!), and at this point I would encourage those still using Linuxbridge to look at it and start asking any questions they have so we have the chance to make it better and can make that process easier.

Thanks for reading,

-Brian, Neutron PTL

[0] https://review.opendev.org/c/openstack/neutron/+/845181 [1] https://review.opendev.org/c/openstack/neutron/+/927216 [2] https://www.jimmdenton.com/migrating-lxb-to-ovn/

I'd be happy with the out-of-tree option, especially if that gives folks such as myself the opportunity to breathe some life back into it and at the very least validate compatibility and have better visibility of the driver's viability in releases post-Zed. -- -Nick On 16 Jan 2025 at 22:03:48, Brian Haley <haleyb.dev@gmail.com> wrote:

Yes, one of the issues is eventlet - we are in the process of migrating all of neutron away from it, and Linuxbridge was one of the open issues. Not doing that will allow us to work on all the other parts.

Could Linuxbridge be moved to an out-of-tree driver like networking-ovn was? I would think that is possible, yes. There is a process for creating such projects, just don't have a link.

-Brian

On 1/16/25 4:47 PM, Dmitriy Rabotyagov wrote:

From what I can recall, the biggest hassle at the moment with the

linuxbridge driver - is that it does rely on the eventlet library.

There's a proposed community goal to replace eventlet [1] , though the

replacement process is time consuming and not really straightforward. So

no active contributors to are ready to takeover this migration process.

While it could be not the only reason, it's one I heard as close to be

one of the most problematic ones during some discussion.

But I'd prefer giving the word to Neutron team here, as they obviously

have better overview here.

And yes, moving the plugin to a separate repo is always an option, and

it can be maintained by a different subset of people, while most of the

content being copied over from existing one.

[1]

https://governance.openstack.org/tc/goals/proposed/remove-eventlet.html

<https://governance.openstack.org/tc/goals/proposed/remove-eventlet.html>

On Thu, 16 Jan 2025, 22:26 Nick Jones, <nick@dischord.org

<mailto:nick@dischord.org>> wrote:

Thanks Mohammed. I'm super out of the loop on governance, structure

etc. so what would that look like in practice - would that give us a

plugin that could be referenced, and it'd be maintained with its own

set of tests etc., presumably copied over / out from the existing

Neutron codebase?

--

-Nick

On 16 Jan 2025 at 21:08:48, Mohammed Naser <mnaser@vexxhost.com

<mailto:mnaser@vexxhost.com>> wrote:

...

I think the best way to go about this would be if someone cares

...

enough to maintain it for them to create networking-linuxbridge in

...

the same way that networking-ovn existed before and they can

...

continue to maintain it there (possibly under the |x| namespace).

...

...

This will remove the burden of continuing to maintain it and those

...

who want to continue to run and maintain it can do it there.

...

...

------------------------------------------------------------------------

...

*From:* Nick Jones <nick@dischord.org <mailto:nick@dischord.org>>

...

*Sent:* January 16, 2025 4:04 PM

...

*To:* Brian Haley <haleyb.dev@gmail.com <mailto:haleyb.dev@gmail.com

...

...

*Cc:* openstack-discuss@lists.openstack.org

...

<mailto:openstack-discuss@lists.openstack.org>

...

<openstack-discuss@lists.openstack.org

...

<mailto:openstack-discuss@lists.openstack.org>>

...

*Subject:* Re: [neutron][upgrades] Linuxbridge driver removal and

...

migration

...

...

You don't often get email from nick@dischord.org

...

<mailto:nick@dischord.org>. Learn why this is important

...

<https://aka.ms/LearnAboutSenderIdentification>

...

...

...

Playing devil's advocate slightly, and as an operator who has had

...

one eye on migration (with no good answers really since it's quite

...

a jump - although I appreciate the efforts that have gone in to

...

showing that it can be done in principal), what would be entailed

...

to reinstate the LinuxBridge driver? It's been rock solid in my

...

case, and its simplicity is really appreciated.

...

...

--

...

...

-Nick

...

...

...

On 14 Jan 2025 at 19:40:26, Brian Haley <haleyb.dev@gmail.com

...

<mailto:haleyb.dev@gmail.com>> wrote:

...

...

Hi Stackers,

...

...

...

...

In 2022, during the Zed cycle, the Neutron team took a step at

...

...

marking

...

...

some items as experimental. One of those was the Linuxbridge

...

...

driver. The

...

...

reason was due to it being unmaintained for a number of cycles,

...

...

and no

...

...

one was able to take on its ownership. The implication of this

...

...

decision

...

...

was that it was consider deprecated, even if not given an official

...

...

warning message.

...

...

...

...

In doing this, all gate jobs were moved into the experimental queue,

...

...

feature-parity with other drivers was deemed unnecessary, and bug

...

...

fixing

...

...

was considered best-effort. Since then, both major distros have

...

...

stopped

...

...

supporting new deployments using Linuxbridge, and have been mainly

...

...

focused on OVN.

...

...

...

...

So what does this mean? We (the neutron cores) have come to the

...

...

conclusion that it is time to take the next step and remove the code

...

...

from the tree [1]. After 5 cycles of being considered experimental

...

...

without any investment it just makes sense. We plan on doing this

...

...

in the

...

...

current Epoxy cycle.

...

...

...

...

We realize that there are still deployments using Linuxbridge, and

...

...

hopefully they have been looking at migration strategies since we

...

...

originally marked the code experimental. This email is another

...

...

push to

...

...

the user community to start looking at this, especially if you are

...

...

planning any new deployments. There has been at least one migration

...

...

guide written at [2] (thanks Jim!), and at this point I would

...

...

encourage

...

...

those still using Linuxbridge to look at it and start asking any

...

...

questions they have so we have the chance to make it better and

...

...

can make

...

...

that process easier.

...

...

...

...

Thanks for reading,

...

...

...

...

-Brian, Neutron PTL

...

...

...

...

[0] https://review.opendev.org/c/openstack/neutron/+/845181

...

...

<https://review.opendev.org/c/openstack/neutron/+/845181>

...

...

[1] https://review.opendev.org/c/openstack/neutron/+/927216

...

...

<https://review.opendev.org/c/openstack/neutron/+/927216>

...

...

[2] https://www.jimmdenton.com/migrating-lxb-to-ovn/

...

...

<https://www.jimmdenton.com/migrating-lxb-to-ovn/>

Hi, Dnia czwartek, 16 stycznia 2025 22:26:35 czas środkowoeuropejski standardowy Nick Jones pisze:

Thanks Mohammed. I'm super out of the loop on governance, structure etc. so what would that look like in practice - would that give us a plugin that could be referenced, and it'd be maintained with its own set of tests etc., presumably copied over / out from the existing Neutron codebase?

There is a guide how you can create new project https://docs.opendev.org/opendev/infra-manual/latest/creators.html. Basically, as Mohammed said, you (or someone else interested in it) would need to create new project like x/networking-linuxbridge and copy all existing linuxbridge related code to that new repo. Such project will still be using opendev infrastructure so you can run e.g. some of the neutron jobs in the project's CI, etc. For the projects in the x/ namespace you can do your releases whenever you need/want to. Such projects are not under the OpenStack Release Team government.

--

-Nick

On 16 Jan 2025 at 21:08:48, Mohammed Naser <mnaser@vexxhost.com> wrote:

...

I think the best way to go about this would be if someone cares enough to maintain it for them to create networking-linuxbridge in the same way that networking-ovn existed before and they can continue to maintain it there (possibly under the x namespace).

This will remove the burden of continuing to maintain it and those who want to continue to run and maintain it can do it there.

------------------------------ *From:* Nick Jones <nick@dischord.org> *Sent:* January 16, 2025 4:04 PM *To:* Brian Haley <haleyb.dev@gmail.com> *Cc:* openstack-discuss@lists.openstack.org < openstack-discuss@lists.openstack.org> *Subject:* Re: [neutron][upgrades] Linuxbridge driver removal and migration

You don't often get email from nick@dischord.org. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification> Playing devil's advocate slightly, and as an operator who has had one eye on migration (with no good answers really since it's quite a jump - although I appreciate the efforts that have gone in to showing that it can be done in principal), what would be entailed to reinstate the LinuxBridge driver? It's been rock solid in my case, and its simplicity is really appreciated.

--

-Nick

On 14 Jan 2025 at 19:40:26, Brian Haley <haleyb.dev@gmail.com> wrote:

Hi Stackers,

In 2022, during the Zed cycle, the Neutron team took a step at marking some items as experimental. One of those was the Linuxbridge driver. The reason was due to it being unmaintained for a number of cycles, and no one was able to take on its ownership. The implication of this decision was that it was consider deprecated, even if not given an official warning message.

In doing this, all gate jobs were moved into the experimental queue, feature-parity with other drivers was deemed unnecessary, and bug fixing was considered best-effort. Since then, both major distros have stopped supporting new deployments using Linuxbridge, and have been mainly focused on OVN.

So what does this mean? We (the neutron cores) have come to the conclusion that it is time to take the next step and remove the code from the tree [1]. After 5 cycles of being considered experimental without any investment it just makes sense. We plan on doing this in the current Epoxy cycle.

We realize that there are still deployments using Linuxbridge, and hopefully they have been looking at migration strategies since we originally marked the code experimental. This email is another push to the user community to start looking at this, especially if you are planning any new deployments. There has been at least one migration guide written at [2] (thanks Jim!), and at this point I would encourage those still using Linuxbridge to look at it and start asking any questions they have so we have the chance to make it better and can make that process easier.

Thanks for reading,

-Brian, Neutron PTL

[0] https://review.opendev.org/c/openstack/neutron/+/845181 [1] https://review.opendev.org/c/openstack/neutron/+/927216 [2] https://www.jimmdenton.com/migrating-lxb-to-ovn/

-- Slawek Kaplonski Principal Software Engineer Red Hat

one other thing to not is that the curent linux bridge supprot in os-vif is only still present because linux bridge is still intree in neutron. we had planned ot delete https://github.com/openstack/os-vif/tree/master/vif_plug_linux_bridge if neutron ever removed it so if we were to move the neutron part out of tree we probably should do the same with that. which may require some nova changes too On 17/01/2025 14:22, Jeremy Stanley wrote:

On 2025-01-17 09:06:24 +0100 (+0100), Sławek Kapłoński wrote: [...]

...

create new project like x/networking-linuxbridge [...] For the projects in the x/ namespace [...]

Well, into some new dedicated namespace anyway. Don't use x/ for anything new, that was the dumping ground for projects whose maintainers never responded to let us know what new namespace they wanted to use.

not in all cases. for some of the stackforage project there was not alternative namespace at the time that made sense i.e. they could not move to openstack as they were not an offial delviery of any openstack project team. so they stayed in x becasue it did nto make sense to make one off namespace for things liek devstack plugins that only existed for devoplment/testing that why https://opendev.org/x/networking-ovs-dpdk and https://opendev.org/x/devstack-plugin-libvirt-qemu are in the x namespace. they were not allowed ot move to the openstack one.

When creating the project, decide on a namespace to group its repositories together in.