[ptg][neutron] Ussuri PTG summary

Tim Bell Tim.Bell at cern.ch
Tue Nov 12 20:38:57 UTC 2019


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



More information about the openstack-discuss mailing list