[neutron] [all] Networking-ovn and neutron convergence
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)
On Fri, Nov 22, 2019 at 10:22 AM Brian Haley <haleyb.dev@gmail.com> wrote:
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?
I'm very much supportive of something like this. The most important thing is figuring out a proper migration path for those that are sitting on ML2/OVS, the last time I had a look at this, it wasn't very straightforward AFAIK.
[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)
On Fri, Nov 22, 2019 at 10:22 AM Brian Haley <haleyb.dev@gmail.com> wrote:
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?
I'm very much supportive of something like this. The most important thing is figuring out a proper migration path for those that are sitting on ML2/OVS, the last time I had a look at this, it wasn't very straightforward AFAIK. you should in theory be able to live migration now which did not work before although when i tried live migrating between ml2/ovs and ml2/linux bridge i found issues so we would need to test ml2/ovs and ml2/ovn and fix any issue we find.
On Fri, 2019-11-22 at 11:17 -0500, Mohammed Naser wrote: the main issue i see is the ovn use geneve as it default segmentaiton type where as ml2/ovs mainly uses vlan,vxlan and to a lesser degre gre. so without adding support for vxlan and gre network types to ovn you would have to change the segmentation type of the existing networks in the db which is an action not supported via the api. i know there is vxaln support ofr external vtep gateway in ovn but its not supproted for tenant networks as far as i know. the other complicaton is that different ml2 drivers do not form mesh networks between each other so even if you used vxlan or genve on both ml2/ovs and ml2/ovn it wont give network connectivity. i know there are migration sripts that kind of allow you to do this as an offline migraton between backends but i dont think there is a way to do this in a rolling fashion so effectivly you need to swap your entire cloud in one go. that is less then ideal even if you can live with the feature gaps between ml2/ovs and ml2/ovn today. with all that said ti woudl be nice to see progress in closing those gaps i have also noted a number of other feature gaps in comments in the spec but i fell like its still proably incomplete.
[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)
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.
Hi, On Fri, Nov 22, 2019 at 05:54:05PM +0100, thomas.morin@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...
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
participants (5)
-
Brian Haley
-
Mohammed Naser
-
Sean Mooney
-
Slawek Kaplonski
-
thomas.morin＠orange.com