[neutron] [all] Networking-ovn and neutron convergence
thomas.morin at orange.com
thomas.morin at orange.com
Fri Nov 22 16:54:05 UTC 2019
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
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
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.
Brian Haley :
> For some time we have been discussing in the Neutron community the
> possibility of including the networking-ovn driver  as one of the
> in-tree Neutron drivers. There is already a spec  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 ,
> and had a discussion at the ops-meetup as well .
> 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  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
>  https://opendev.org/openstack/networking-ovn
>  https://review.opendev.org/#/c/658414/
>  https://etherpad.openstack.org/p/Shanghai-Neutron-Planning-restored
> Lines 252 - 295
>  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.
More information about the openstack-discuss