Open Stack

Hi,

After the neutron PTG session on the future of ML2/LinuxBridge,
I discussed this topic in the ops-meetup PTG room (L.43- in [1]).

- A lot of needs for Linux Bridge driver was expressed in the room.
- LB is for simple network and many ops need it to keep deployment
simple including a provider network without L3 feature.
- The stats on Linux Bridge usage were shared as well. LB still has a
large user base.  40% use Linux Bridge driver according to a survey in
Wed's ops(?) session
and the user survey last Oct shows 33% use Linux Bridge driver (63%
use OVS based) [2].

This discussion does not mean the deprecation of the linux bridge driver.
In my understanding, the main motivation is how the neutron team can
keep the reference implementations simple.
One example is that the features supported in the linux bridge driver
are behind those in the OVS driver
and some developers think this is the lack of the interest for the
linux bridge driver, but this may show that
most/not small number of linux bridge users just want simple features.

That's my understanding in the PTG. Hope it helps the discussion :)

Thanks,
Akihiro

[1] https://etherpad.openstack.org/p/shanghai-ptg-ops-meetup
[2] Deployment Decisions in https://www.openstack.org/analytics

On Wed, Nov 13, 2019 at 8:21 PM Slawek Kaplonski <skaplons at redhat.com> wrote:
>
> Hi,
>
> On Wed, Nov 13, 2019 at 04:31:20AM +0000, James Denton wrote:
> > Appreciate the summary as well.
> >
> > For what it's worth, the ML2/LinuxBridge combo has been a very stable setup for us since its inception, and I'd hate to see it deprecated and removed for the sake of removing something. Last I checked, trunk ports were supported with the ML2/LinuxBridge driver. And while of course DVR is not a supported feature, a good number of our ML2/LXB environments forgo Neutron routers altogether in favor of putting VMs on the provider network. It has shown to be as performant as vanilla OVS, and a simpler model to implement and support as an operator.
>
> You're right. Trunk ports are ofcourse supported by LB agent. But e.g. some of
> QoS rules aren't supported by this backend.
>
> >
> > Just my two cents.
> >
> > Thanks,
> >
> > James Denton
> > Network Engineer
> > Rackspace Private Cloud
> > james.denton at rackspace.com
> >
> > On 11/12/19, 3:41 PM, "Tim Bell" <Tim.Bell at cern.ch> wrote:
> >
> >     CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!
> >
> >
> >     Many thanks for the summaries. It’s really helpful for those who could not be in the discussions.
> >
> >     CERN are also using ML2/Linuxbridge so we’d welcome being involved in any deprecation discussions and migration paths.
> >
> >     Tim
> >
> >     > On 12 Nov 2019, at 14:53, Slawek Kaplonski <skaplons at redhat.com> wrote:
> >     >
> >     > Hi Neutron team,
> >     >
> >     > First if all thank to all of You for great and very productive week during the
> >     > PTG in Shanghai.
> >     > Below is summary of our discussions from whole 3 days.
> >     > If I forgot about something, please respond to the email and update missing
> >     > informations. But if You want to have follow up discussion about one of the
> >     > topics from this summary, please start a new thread to keep this one only as
> >     > high level summary of the PTG.
> >     >
> >     > ...
> >
> >     > Starting the process of removing ML2/Linuxbridge
> >     > ================================================
> >     >
> >     > Currently in Neutron tree we have 4 drivers:
> >     > * Linuxbridge,
> >     > * Openvswitch,
> >     > * macvtap,
> >     > * sriov.
> >     > SR-IOV driver is out of discussion here as this driver is
> >     > addressing slightly different use case than other out drivers.
> >     >
> >     > We started discussion about above topic because we don't want to end up with too
> >     > many drivers in-tree and we also had some discussions (and we have spec for that
> >     > already) about include networking-ovn as in-tree driver.
> >     > So with networking-ovn in-tree we would have already 4 drivers which can be used
> >     > on any hardware: linuxbridge, ovs, macvtap and ovn.
> >     > Conclusions from the discussion are:
> >     > * each driver requires proper testing in the gate, so we need to add many new
> >     >  jobs to our check/gate queue,
> >     > * currently linuxbridge driver don't have a lot of development and feature
> >     >  parity gaps between linuxbridge and ovs drivers is getting bigger and bigger
> >     >  (e.g. dvr, trunk ports),
> >     > * also macvtap driver don't have a lot of activity in last few cycles. Maybe
> >     >  this one could be also considered as candidate to deprecation,
> >     > * we need to have process of deprecating some drivers and time horizon for such
> >     >  actions should be at least 2 cycles.
> >     > * we will not remove any driver completly but rather we will move it to be in
> >     >  stadium process first so it still can be maintained by people who are
> >     >  interested in it.
> >     >
> >     > Actions to do after this discussion:
> >     > * Miguel Lavalle will contact RAX and Godaddy (we know that those are
> >     >  Linuxbridge users currently) to ask about their feedback about this,
> >     > * if there are any other companies using LB driver, Nate Johnston is willing to
> >     >  help conctating them, please reach to him in such case.
> >     > * we may ratify marking linuxbridge as deprecated in the team meeting during
> >     >  Ussuri cycle if nothing surprising pops in.
> >     >
> >
> >
> >
>
> --
> Slawek Kaplonski
> Senior software engineer
> Red Hat
>
>