Open Stack

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.

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.