Hi Everybody,
Just my points to have it written here also.
Around Neutron we have an ecosystem of networking projects, the Stadiums which give extra networking features or special drivers for Operators.
The Neutron core team governs these and helps in the maintenance of them (like making CI jobs passing when new requirements are popping or we have to move jobs to new distro or similar).
There is a need for active users for these projects who jump in to triage bugs if the Neutron cores lack the deep background knowledge of the given area or fix these issues or push changes like the above mentioned eventlet work.
I suppose when we say networking-linuxbridge project the first option is to have it as a Stadium project (see [1]).
An even lighter option can be to cut out the code to networking-linuxbridge but instead of having it in openstack/ namespace move it to x/ where the code can live but no governance and maintenance from the Neutron core team.
So these must be also considered when thinking about options to keep LB driver alive for some more releases.

[1]: https://docs.openstack.org/neutron/latest/contributor/stadium/

Best wishes
Lajos Katona (lajoskatona)

Nick Jones <nick@dischord.org> ezt írta (időpont: 2025. jan. 16., Cs, 23:26):
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/>