Open Stack

Hi,

On Fri, Nov 22, 2019 at 05:54:05PM +0100, thomas.morin at orange.com wrote:
> Hi Brian, all,
> 
> Perhaps the area to make more explicit is where the difference may lie
> between having networking-ovn "as one of the in-tree Neutron drivers" and
> "the ML2+OVS+DVR solution will be merged with the networking-ovn solution"
> [1].
> 
> More specifically, my question would be about whether or not this proposal
> includes removing ML2 code, and if yes which parts, and in particular
> whether the l2 agent extension integration point would be preserved.  Not
> preserving them would be a problem for projects such as networking-bagpipe,
> networking-bgpvpn and networking-sfc to exist for Ussuri release.

We are for sure not going to remove any code (if it's not simple duplicate code)
from existing ML2/OVS implementation. This is very popular solution in Neutron,
used by many clouds so we for sure will need to maintain it too still :)

> 
> These three projects have a different level of liveliness, but I would find
> problematic a choice that would prevent keeping networking-bgpvpn and it's
> reference implementation in networking-bagpipe, to be released for Ussuri. 
> Having OVN include BGPVPN functionality is something that had been discussed
> in the past, and the idea is still valid in my views, but it's unlikely that
> such a thing could land in Ussuri timeframe.
> 
> So I would be glad if this specific point of preserving integration points
> that ML2 offers, can be clarified.
> 
> Best,
> 
> -Thomas
> 
> [1] https://review.opendev.org/#/c/658414/18/specs/ussuri/ml2ovs-ovn-convergence.rst@52
> 
> 
> Brian Haley :
> > Hi,
> > 
> > For some time we have been discussing in the Neutron community the
> > possibility of including the networking-ovn driver [1] as one of the
> > in-tree Neutron drivers.  There is already a spec [2] describing in
> > detail why we want to do this and why we think it is good idea.  We also
> > discussed this during the PTG in Shanghai within our team [3], and had a
> > discussion at the ops-meetup as well [4].
> > 
> > The OVN backend is free of many well-known issues which are impacting
> > the existing ML2/OVS reference implementation today with the OVS agent.
> > For example, OVN provides:
> > 
> > * Control plane performance optimizations by not using rabbitmq;
> > * DVR (and HA) by default, based on OpenFlow so it can be easy offloaded
> >   e.g. by SmartNICs;
> > * Distributed DHCP;
> > 
> > There are some feature parity gaps when comparing it to ML2/OVS that we
> > plan to address.  See [2] for details.
> > 
> > We think that merging this code into the neutron repository will help to
> > grow the networking-ovn community and will help us to keep a healthy
> > Neutron team as well by increasing the number or contributors.
> > 
> > Our current plan is to start merging code from networking-ovn into the
> > neutron repository as soon as possible in the Ussuri cycle. But we also
> > wanted to get any additional opinions from the wider community about
> > this plan.  What do users and operators of Neutron think about this?
> > 
> > [1] https://opendev.org/openstack/networking-ovn
> > [2] https://review.opendev.org/#/c/658414/
> > [3] https://etherpad.openstack.org/p/Shanghai-Neutron-Planning-restored
> >     Lines 252 - 295
> > [4] https://etherpad.openstack.org/p/shanghai-ptg-ops-meetup
> >     Lines 62 - 69
> > 
> > Thanks for any feedback,
> > 
> > -Brian (and Slawek)
> > 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> 

-- 
Slawek Kaplonski
Senior software engineer
Red Hat