Open Stack

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.

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.
    >