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