[All][Neutron][Devstack] OVN as the Default Devstack Neutron Backend
Hi, The Neutron team wants to propose a switch of the default Neutron backend in Devstack from OVS (neutron-ovs-agent, neutron-dhcp-agent, neutron-l3-agent) to OVN with its own ovn-metadata-agent and ovn-controller. We discussed that change during the virtual PTG - see [1]. In this document we want to explain reasons why we want to do that change. OVN in 75 Words --------------- Open Virtual Network is managed under the OVS project, and was created by the original authors of OVS. It is an attempt to re-do the ML2/OVS control plane, using lessons learned throughout the years. It is intended to be used in projects such as OpenStack and Kubernetes. OVN has a different architecture, moving us away from Python agents communicating with the Neutron API service via RabbitMQ to C daemons communicating via OpenFlow and OVSDB. Here’s a heap of information about OpenStack’s integration of OVN: * OpenStack Boston Summit talk on OVN [2] * Upstream OpenStack networking-ovn documentation [3] and [4] * OSP 13 OVN documentation, including how to install it using Director [5] Neutron OVN driver was developed as a Neutron stadium project, "networking-ovn". In the Ussuri cycle, networking-ovn was merged into the main Neutron repository. Why? ---- In the Neutron team we believe that OVN and the Neutron OVN driver are built with a modern architecture that offers better foundations for a simpler and more performant solution. We see increased participation in kubernetes-ovn, resulting in a larger core OVN community, and we would like OpenStack to benefit from this Kubernetes driven OVN investment. Neutron OVN driver currently has got some feature parity gaps comparing to ML2/OVS (see [6] for details) but our team is working hard to close those gaps and we believe that this driver is the future for Neutron and that’s why we want to make it the default Neutron ML2 backend in the Devstack configuration. What Does it Mean? ------------------ Since most Openstack projects use Neutron in their CI and gate jobs, this change has the potential for a large impact. But this backend is already tested with various jobs in the Neutron CI and it works fine. Recently (See [7]) we also proposed to add an OVN based job to the Devstack’s check queue. Similarly the default Neutron backend in TripleO was changed in the Stein cycle and there were no any significant issues related strictly to this change. It worked well for other projects. Of course in the Neutron project we will be still gating other drivers, like ML2/Linuxbridge and ML2/OVS - nothing will change here, except for the names of some of the jobs. The Neutron team is *NOT* going to deprecate any of the other existing ML2 drivers. We will be still maintaining Linuxbridge, OVS and other in-tree drivers in the same way as it is now. Action Plan ----------- We want to make this change before the Victoria-2 milestone to not make such changes too late in the release cycle. Our action plan is as below: 1. Share the plan and get feedback from the upstream community (this thread) 2. Move OVN related Devstack code from a plugin defined in the Neutron repo to Devstack repo - we don’t want to force everyone else to add “enable_plugin neutron” in their local.conf file to use default Neutron backend, 3. Switch default Neutron backend in Devstack to be OVN, a. Switch definition of base devstack CI jobs that it will run Neutron with OVN backend, 4. Propose DNM patches depend on patch from point 3 and 3a to main OpenStack projects to check if it will not break anything in the gate of those projects. 5. If all will be running fine, merge patches proposed in points 3 and 3a. [1] https://etherpad.opendev.org/p/neutron-victoria-ptg - Lines 185 - 193 [2] https://www.youtube.com/watch?v=sgc7myiX6ts [3] https://docs.openstack.org/neutron/latest/admin/ovn/index.html [4] https://docs.openstack.org/neutron/latest/ovn/index.html [5] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/... [6] https://docs.openstack.org/neutron/latest/ovn/gaps.html [7] https://review.opendev.org/#/c/736021/ -- Slawek Kaplonski Senior software engineer Red Hat
Hi, Bump. Anyone has got any thoughts about it?
On 23 Jun 2020, at 12:24, Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
The Neutron team wants to propose a switch of the default Neutron backend in Devstack from OVS (neutron-ovs-agent, neutron-dhcp-agent, neutron-l3-agent) to OVN with its own ovn-metadata-agent and ovn-controller. We discussed that change during the virtual PTG - see [1]. In this document we want to explain reasons why we want to do that change.
OVN in 75 Words ---------------
Open Virtual Network is managed under the OVS project, and was created by the original authors of OVS. It is an attempt to re-do the ML2/OVS control plane, using lessons learned throughout the years. It is intended to be used in projects such as OpenStack and Kubernetes. OVN has a different architecture, moving us away from Python agents communicating with the Neutron API service via RabbitMQ to C daemons communicating via OpenFlow and OVSDB.
Here’s a heap of information about OpenStack’s integration of OVN: * OpenStack Boston Summit talk on OVN [2] * Upstream OpenStack networking-ovn documentation [3] and [4] * OSP 13 OVN documentation, including how to install it using Director [5]
Neutron OVN driver was developed as a Neutron stadium project, "networking-ovn". In the Ussuri cycle, networking-ovn was merged into the main Neutron repository.
Why? ----
In the Neutron team we believe that OVN and the Neutron OVN driver are built with a modern architecture that offers better foundations for a simpler and more performant solution. We see increased participation in kubernetes-ovn, resulting in a larger core OVN community, and we would like OpenStack to benefit from this Kubernetes driven OVN investment. Neutron OVN driver currently has got some feature parity gaps comparing to ML2/OVS (see [6] for details) but our team is working hard to close those gaps and we believe that this driver is the future for Neutron and that’s why we want to make it the default Neutron ML2 backend in the Devstack configuration.
What Does it Mean? ------------------
Since most Openstack projects use Neutron in their CI and gate jobs, this change has the potential for a large impact. But this backend is already tested with various jobs in the Neutron CI and it works fine. Recently (See [7]) we also proposed to add an OVN based job to the Devstack’s check queue. Similarly the default Neutron backend in TripleO was changed in the Stein cycle and there were no any significant issues related strictly to this change. It worked well for other projects. Of course in the Neutron project we will be still gating other drivers, like ML2/Linuxbridge and ML2/OVS - nothing will change here, except for the names of some of the jobs. The Neutron team is *NOT* going to deprecate any of the other existing ML2 drivers. We will be still maintaining Linuxbridge, OVS and other in-tree drivers in the same way as it is now.
Action Plan -----------
We want to make this change before the Victoria-2 milestone to not make such changes too late in the release cycle. Our action plan is as below:
1. Share the plan and get feedback from the upstream community (this thread) 2. Move OVN related Devstack code from a plugin defined in the Neutron repo to Devstack repo - we don’t want to force everyone else to add “enable_plugin neutron” in their local.conf file to use default Neutron backend, 3. Switch default Neutron backend in Devstack to be OVN, a. Switch definition of base devstack CI jobs that it will run Neutron with OVN backend, 4. Propose DNM patches depend on patch from point 3 and 3a to main OpenStack projects to check if it will not break anything in the gate of those projects. 5. If all will be running fine, merge patches proposed in points 3 and 3a.
[1] https://etherpad.opendev.org/p/neutron-victoria-ptg - Lines 185 - 193 [2] https://www.youtube.com/watch?v=sgc7myiX6ts [3] https://docs.openstack.org/neutron/latest/admin/ovn/index.html [4] https://docs.openstack.org/neutron/latest/ovn/index.html [5] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/... [6] https://docs.openstack.org/neutron/latest/ovn/gaps.html [7] https://review.opendev.org/#/c/736021/
-- Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Principal software engineer Red Hat
From an operator's view, after getting familiar with OVN, there is a lot of work that needs to be done behind
Hello Slawek, This is very interesting and I think this is the right way to go, speakin from an operator standpoint here. We've started investing time in getting familiar with OVN, how to operate and how to troubleshoot and are looking forward into offloading a lot of work to OVN in the future. We are closely looking how we can integrate hardware offloading with OVN+OVS to improve our performance and in the future looking to the new VirtIO backend support for vDPA that has started to mature more. the scenes in order to get to the desired point. * Geneve offloading on NIC, we might need new NICs or new firmware. * We need to migrate away from VXLAN to Geneve encapsulation, how can we migrate our current baremetal approach * We need to have Neutron migrate from ML2 OVS to ML2 OVN, I know Red Hat has driven some work to perform this (an Geneve migration) but there is minimal testing or real world deployments that has tried or documented the approach. * And then all misc stuff, we need to look into the new ovn-metadata-agent, should we move Octavia over to OVN yet? Then the final, what do we gain vs what do we lose in terms of maintainability, performance and features. But form an operator's view, I'm very positive to the future of a OVN integrated OpenStack. Best regards Tobias ________________________________________ From: Slawek Kaplonski <skaplons@redhat.com> Sent: Tuesday, June 23, 2020 12:24 PM To: OpenStack Discuss ML Cc: Assaf Muller; Daniel Alvarez Sanchez Subject: [All][Neutron][Devstack] OVN as the Default Devstack Neutron Backend Hi, The Neutron team wants to propose a switch of the default Neutron backend in Devstack from OVS (neutron-ovs-agent, neutron-dhcp-agent, neutron-l3-agent) to OVN with its own ovn-metadata-agent and ovn-controller. We discussed that change during the virtual PTG - see [1]. In this document we want to explain reasons why we want to do that change. OVN in 75 Words --------------- Open Virtual Network is managed under the OVS project, and was created by the original authors of OVS. It is an attempt to re-do the ML2/OVS control plane, using lessons learned throughout the years. It is intended to be used in projects such as OpenStack and Kubernetes. OVN has a different architecture, moving us away from Python agents communicating with the Neutron API service via RabbitMQ to C daemons communicating via OpenFlow and OVSDB. Here’s a heap of information about OpenStack’s integration of OVN: * OpenStack Boston Summit talk on OVN [2] * Upstream OpenStack networking-ovn documentation [3] and [4] * OSP 13 OVN documentation, including how to install it using Director [5] Neutron OVN driver was developed as a Neutron stadium project, "networking-ovn". In the Ussuri cycle, networking-ovn was merged into the main Neutron repository. Why? ---- In the Neutron team we believe that OVN and the Neutron OVN driver are built with a modern architecture that offers better foundations for a simpler and more performant solution. We see increased participation in kubernetes-ovn, resulting in a larger core OVN community, and we would like OpenStack to benefit from this Kubernetes driven OVN investment. Neutron OVN driver currently has got some feature parity gaps comparing to ML2/OVS (see [6] for details) but our team is working hard to close those gaps and we believe that this driver is the future for Neutron and that’s why we want to make it the default Neutron ML2 backend in the Devstack configuration. What Does it Mean? ------------------ Since most Openstack projects use Neutron in their CI and gate jobs, this change has the potential for a large impact. But this backend is already tested with various jobs in the Neutron CI and it works fine. Recently (See [7]) we also proposed to add an OVN based job to the Devstack’s check queue. Similarly the default Neutron backend in TripleO was changed in the Stein cycle and there were no any significant issues related strictly to this change. It worked well for other projects. Of course in the Neutron project we will be still gating other drivers, like ML2/Linuxbridge and ML2/OVS - nothing will change here, except for the names of some of the jobs. The Neutron team is *NOT* going to deprecate any of the other existing ML2 drivers. We will be still maintaining Linuxbridge, OVS and other in-tree drivers in the same way as it is now. Action Plan ----------- We want to make this change before the Victoria-2 milestone to not make such changes too late in the release cycle. Our action plan is as below: 1. Share the plan and get feedback from the upstream community (this thread) 2. Move OVN related Devstack code from a plugin defined in the Neutron repo to Devstack repo - we don’t want to force everyone else to add “enable_plugin neutron” in their local.conf file to use default Neutron backend, 3. Switch default Neutron backend in Devstack to be OVN, a. Switch definition of base devstack CI jobs that it will run Neutron with OVN backend, 4. Propose DNM patches depend on patch from point 3 and 3a to main OpenStack projects to check if it will not break anything in the gate of those projects. 5. If all will be running fine, merge patches proposed in points 3 and 3a. [1] https://etherpad.opendev.org/p/neutron-victoria-ptg - Lines 185 - 193 [2] https://www.youtube.com/watch?v=sgc7myiX6ts [3] https://docs.openstack.org/neutron/latest/admin/ovn/index.html [4] https://docs.openstack.org/neutron/latest/ovn/index.html [5] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/... [6] https://docs.openstack.org/neutron/latest/ovn/gaps.html [7] https://review.opendev.org/#/c/736021/ -- Slawek Kaplonski Senior software engineer Red Hat
Hi, Thx for Your feedback.
On 6 Jul 2020, at 11:49, Tobias Urdin <tobias.urdin@binero.com> wrote:
Hello Slawek, This is very interesting and I think this is the right way to go, speakin from an operator standpoint here.
We've started investing time in getting familiar with OVN, how to operate and how to troubleshoot and are looking forward into offloading a lot of work to OVN in the future.
We are closely looking how we can integrate hardware offloading with OVN+OVS to improve our performance and in the future looking to the new VirtIO backend support for vDPA that has started to mature more.
From an operator's view, after getting familiar with OVN, there is a lot of work that needs to be done behind the scenes in order to get to the desired point.
* Geneve offloading on NIC, we might need new NICs or new firmware. * We need to migrate away from VXLAN to Geneve encapsulation, how can we migrate our current baremetal approach * We need to have Neutron migrate from ML2 OVS to ML2 OVN, I know Red Hat has driven some work to perform this (an Geneve migration) but there is minimal testing or real world deployments that has tried or documented the approach.
Yes, that’s definitely something which will require more work.
* And then all misc stuff, we need to look into the new ovn-metadata-agent, should we move Octavia over to OVN yet?
For octavia, there is ovn-octavia provider: https://opendev.org/openstack/ovn-octavia-provider which You can use with OVN instead of using Amphora
Then the final, what do we gain vs what do we lose in terms of maintainability, performance and features.
We have document https://docs.openstack.org/neutron/latest/ovn/gaps.html which should describe most of the gaps between ML2/OVS and ML2/OVN backends. We are working on closing those gaps but please also keep in mind that ML2/OVS is not going anywhere, if You need any of features from it, You can still use it as it still is and will be maintained backend :)
But form an operator's view, I'm very positive to the future of a OVN integrated OpenStack.
Thx. I really appreciate this.
Best regards Tobias ________________________________________ From: Slawek Kaplonski <skaplons@redhat.com> Sent: Tuesday, June 23, 2020 12:24 PM To: OpenStack Discuss ML Cc: Assaf Muller; Daniel Alvarez Sanchez Subject: [All][Neutron][Devstack] OVN as the Default Devstack Neutron Backend
Hi,
The Neutron team wants to propose a switch of the default Neutron backend in Devstack from OVS (neutron-ovs-agent, neutron-dhcp-agent, neutron-l3-agent) to OVN with its own ovn-metadata-agent and ovn-controller. We discussed that change during the virtual PTG - see [1]. In this document we want to explain reasons why we want to do that change.
OVN in 75 Words ---------------
Open Virtual Network is managed under the OVS project, and was created by the original authors of OVS. It is an attempt to re-do the ML2/OVS control plane, using lessons learned throughout the years. It is intended to be used in projects such as OpenStack and Kubernetes. OVN has a different architecture, moving us away from Python agents communicating with the Neutron API service via RabbitMQ to C daemons communicating via OpenFlow and OVSDB.
Here’s a heap of information about OpenStack’s integration of OVN: * OpenStack Boston Summit talk on OVN [2] * Upstream OpenStack networking-ovn documentation [3] and [4] * OSP 13 OVN documentation, including how to install it using Director [5]
Neutron OVN driver was developed as a Neutron stadium project, "networking-ovn". In the Ussuri cycle, networking-ovn was merged into the main Neutron repository.
Why? ----
In the Neutron team we believe that OVN and the Neutron OVN driver are built with a modern architecture that offers better foundations for a simpler and more performant solution. We see increased participation in kubernetes-ovn, resulting in a larger core OVN community, and we would like OpenStack to benefit from this Kubernetes driven OVN investment. Neutron OVN driver currently has got some feature parity gaps comparing to ML2/OVS (see [6] for details) but our team is working hard to close those gaps and we believe that this driver is the future for Neutron and that’s why we want to make it the default Neutron ML2 backend in the Devstack configuration.
What Does it Mean? ------------------
Since most Openstack projects use Neutron in their CI and gate jobs, this change has the potential for a large impact. But this backend is already tested with various jobs in the Neutron CI and it works fine. Recently (See [7]) we also proposed to add an OVN based job to the Devstack’s check queue. Similarly the default Neutron backend in TripleO was changed in the Stein cycle and there were no any significant issues related strictly to this change. It worked well for other projects. Of course in the Neutron project we will be still gating other drivers, like ML2/Linuxbridge and ML2/OVS - nothing will change here, except for the names of some of the jobs. The Neutron team is *NOT* going to deprecate any of the other existing ML2 drivers. We will be still maintaining Linuxbridge, OVS and other in-tree drivers in the same way as it is now.
Action Plan -----------
We want to make this change before the Victoria-2 milestone to not make such changes too late in the release cycle. Our action plan is as below:
1. Share the plan and get feedback from the upstream community (this thread) 2. Move OVN related Devstack code from a plugin defined in the Neutron repo to Devstack repo - we don’t want to force everyone else to add “enable_plugin neutron” in their local.conf file to use default Neutron backend, 3. Switch default Neutron backend in Devstack to be OVN, a. Switch definition of base devstack CI jobs that it will run Neutron with OVN backend, 4. Propose DNM patches depend on patch from point 3 and 3a to main OpenStack projects to check if it will not break anything in the gate of those projects. 5. If all will be running fine, merge patches proposed in points 3 and 3a.
[1] https://etherpad.opendev.org/p/neutron-victoria-ptg - Lines 185 - 193 [2] https://www.youtube.com/watch?v=sgc7myiX6ts [3] https://docs.openstack.org/neutron/latest/admin/ovn/index.html [4] https://docs.openstack.org/neutron/latest/ovn/index.html [5] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/... [6] https://docs.openstack.org/neutron/latest/ovn/gaps.html [7] https://review.opendev.org/#/c/736021/
-- Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Principal software engineer Red Hat
On Thu, Jul 9, 2020 at 11:45 AM Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
Thx for Your feedback.
On 6 Jul 2020, at 11:49, Tobias Urdin <tobias.urdin@binero.com> wrote:
Hello Slawek, This is very interesting and I think this is the right way to go, speakin from an operator standpoint here.
We've started investing time in getting familiar with OVN, how to operate and how to troubleshoot and are looking forward into offloading a lot of work to OVN in the future.
We are closely looking how we can integrate hardware offloading with OVN+OVS to improve our performance and in the future looking to the new VirtIO backend support for vDPA that has started to mature more.
From an operator's view, after getting familiar with OVN, there is a lot of work that needs to be done behind the scenes in order to get to the desired point.
* Geneve offloading on NIC, we might need new NICs or new firmware. * We need to migrate away from VXLAN to Geneve encapsulation, how can we migrate our current baremetal approach * We need to have Neutron migrate from ML2 OVS to ML2 OVN, I know Red Hat has driven some work to perform this (an Geneve migration) but there is minimal testing or real world deployments that has tried or documented the approach.
Yes, that’s definitely something which will require more work.
* And then all misc stuff, we need to look into the new ovn-metadata-agent, should we move Octavia over to OVN yet?
For octavia, there is ovn-octavia provider: https://opendev.org/openstack/ovn-octavia-provider which You can use with OVN instead of using Amphora
Before an attempt at moving from amphora to OVN load balancers, it's worth considering all the existing feature limitations of the OVN provider. OVN load balancers do not support a large feature set typically available in other load balancer solutions. For example, OVN does not support: - Round-robin, weighted round-robin, least connection, source IP, etc. It does only support one balancing algorithm: source IP-Port - HTTP, HTTPS, Proxy protocols. OVN only supports TCP and UDP with limited capabilities (e.g. no timeout knobs) - TLS termination - TLS client authentication - TLS backend encryption - Layer 7 features and header manipulation - Health monitors (WIP) - Octavia flavors - Statistics - Mixed IPv6 and IPv4 VIPs and members. More details in https://docs.openstack.org/octavia/latest/user/feature-classification/index....
Then the final, what do we gain vs what do we lose in terms of
maintainability, performance and features.
We have document https://docs.openstack.org/neutron/latest/ovn/gaps.html which should describe most of the gaps between ML2/OVS and ML2/OVN backends. We are working on closing those gaps but please also keep in mind that ML2/OVS is not going anywhere, if You need any of features from it, You can still use it as it still is and will be maintained backend :)
But form an operator's view, I'm very positive to the future of a OVN
integrated OpenStack.
Thx. I really appreciate this.
Best regards Tobias ________________________________________ From: Slawek Kaplonski <skaplons@redhat.com> Sent: Tuesday, June 23, 2020 12:24 PM To: OpenStack Discuss ML Cc: Assaf Muller; Daniel Alvarez Sanchez Subject: [All][Neutron][Devstack] OVN as the Default Devstack Neutron
Backend
Hi,
The Neutron team wants to propose a switch of the default Neutron
Devstack from OVS (neutron-ovs-agent, neutron-dhcp-agent, neutron-l3-agent) to OVN with its own ovn-metadata-agent and ovn-controller. We discussed that change during the virtual PTG - see [1]. In this document we want to explain reasons why we want to do that change.
OVN in 75 Words ---------------
Open Virtual Network is managed under the OVS project, and was created by the original authors of OVS. It is an attempt to re-do the ML2/OVS control
using lessons learned throughout the years. It is intended to be used in projects such as OpenStack and Kubernetes. OVN has a different architecture, moving us away from Python agents communicating with the Neutron API service via RabbitMQ to C daemons communicating via OpenFlow and OVSDB.
Here’s a heap of information about OpenStack’s integration of OVN: * OpenStack Boston Summit talk on OVN [2] * Upstream OpenStack networking-ovn documentation [3] and [4] * OSP 13 OVN documentation, including how to install it using Director [5]
Neutron OVN driver was developed as a Neutron stadium project, "networking-ovn". In the Ussuri cycle, networking-ovn was merged into
Neutron repository.
Why? ----
In the Neutron team we believe that OVN and the Neutron OVN driver are built with a modern architecture that offers better foundations for a simpler and more performant solution. We see increased participation in kubernetes-ovn, resulting in a larger core OVN community, and we would like OpenStack to benefit from this Kubernetes driven OVN investment. Neutron OVN driver currently has got some feature parity gaps comparing to ML2/OVS (see [6] for details) but our team is working hard to close
and we believe that this driver is the future for Neutron and that’s why we want to make it the default Neutron ML2 backend in the Devstack configuration.
What Does it Mean? ------------------
Since most Openstack projects use Neutron in their CI and gate jobs, this change has the potential for a large impact. But this backend is already tested with various jobs in the Neutron CI and it works fine. Recently (See [7]) we also proposed to add an OVN based job to the Devstack’s check queue. Similarly the default Neutron backend in TripleO was changed in the Stein cycle and there were no any significant issues related strictly to this change. It worked well for other projects. Of course in the Neutron project we will be still gating other drivers,
ML2/Linuxbridge and ML2/OVS - nothing will change here, except for the names of some of the jobs. The Neutron team is *NOT* going to deprecate any of the other existing ML2 drivers. We will be still maintaining Linuxbridge, OVS and other in-tree drivers in the same way as it is now.
Action Plan -----------
We want to make this change before the Victoria-2 milestone to not make such changes too late in the release cycle. Our action plan is as below:
1. Share the plan and get feedback from the upstream community (this
2. Move OVN related Devstack code from a plugin defined in the Neutron repo to Devstack repo - we don’t want to force everyone else to add “enable_plugin neutron” in their local.conf file to use default Neutron backend, 3. Switch default Neutron backend in Devstack to be OVN, a. Switch definition of base devstack CI jobs that it will run Neutron with OVN backend, 4. Propose DNM patches depend on patch from point 3 and 3a to main OpenStack projects to check if it will not break anything in the gate of those
backend in plane, the main those gaps like thread) projects.
5. If all will be running fine, merge patches proposed in points 3 and 3a.
[1] https://etherpad.opendev.org/p/neutron-victoria-ptg - Lines 185 - 193 [2] https://www.youtube.com/watch?v=sgc7myiX6ts [3] https://docs.openstack.org/neutron/latest/admin/ovn/index.html [4] https://docs.openstack.org/neutron/latest/ovn/index.html [5] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/... [6] https://docs.openstack.org/neutron/latest/ovn/gaps.html [7] https://review.opendev.org/#/c/736021/
-- Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Principal software engineer Red Hat
On Thu, Jul 9, 2020 at 7:17 AM Carlos Goncalves <cgoncalves@redhat.com> wrote:
On Thu, Jul 9, 2020 at 11:45 AM Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
Thx for Your feedback.
On 6 Jul 2020, at 11:49, Tobias Urdin <tobias.urdin@binero.com> wrote:
Hello Slawek, This is very interesting and I think this is the right way to go, speakin from an operator standpoint here.
We've started investing time in getting familiar with OVN, how to operate and how to troubleshoot and are looking forward into offloading a lot of work to OVN in the future.
We are closely looking how we can integrate hardware offloading with OVN+OVS to improve our performance and in the future looking to the new VirtIO backend support for vDPA that has started to mature more.
From an operator's view, after getting familiar with OVN, there is a lot of work that needs to be done behind the scenes in order to get to the desired point.
* Geneve offloading on NIC, we might need new NICs or new firmware. * We need to migrate away from VXLAN to Geneve encapsulation, how can we migrate our current baremetal approach * We need to have Neutron migrate from ML2 OVS to ML2 OVN, I know Red Hat has driven some work to perform this (an Geneve migration) but there is minimal testing or real world deployments that has tried or documented the approach.
Yes, that’s definitely something which will require more work.
* And then all misc stuff, we need to look into the new ovn-metadata-agent, should we move Octavia over to OVN yet?
For octavia, there is ovn-octavia provider: https://opendev.org/openstack/ovn-octavia-provider which You can use with OVN instead of using Amphora
Before an attempt at moving from amphora to OVN load balancers, it's worth considering all the existing feature limitations of the OVN provider.
OVN load balancers do not support a large feature set typically available in other load balancer solutions. For example, OVN does not support:
- Round-robin, weighted round-robin, least connection, source IP, etc. It does only support one balancing algorithm: source IP-Port - HTTP, HTTPS, Proxy protocols. OVN only supports TCP and UDP with limited capabilities (e.g. no timeout knobs) - TLS termination - TLS client authentication - TLS backend encryption - Layer 7 features and header manipulation - Health monitors (WIP) - Octavia flavors - Statistics - Mixed IPv6 and IPv4 VIPs and members.
More details in https://docs.openstack.org/octavia/latest/user/feature-classification/index....
Exactly. The Amphora and OVN drivers: a) Can be loaded at the same time b) Users can choose which driver to use per LB c) Are complementary, they don't replace one another The intention is that you could use an OVN based LB for 'simple' use cases, where you don't require any of the functionality Carlos highlighted above, and Amphora for the rest. The assumption here is that for simple use cases OVN based LBs perform and scale better, though we haven't quite been able to confirm that yet.
Then the final, what do we gain vs what do we lose in terms of maintainability, performance and features.
We have document https://docs.openstack.org/neutron/latest/ovn/gaps.html which should describe most of the gaps between ML2/OVS and ML2/OVN backends. We are working on closing those gaps but please also keep in mind that ML2/OVS is not going anywhere, if You need any of features from it, You can still use it as it still is and will be maintained backend :)
But form an operator's view, I'm very positive to the future of a OVN integrated OpenStack.
Thx. I really appreciate this.
Best regards Tobias ________________________________________ From: Slawek Kaplonski <skaplons@redhat.com> Sent: Tuesday, June 23, 2020 12:24 PM To: OpenStack Discuss ML Cc: Assaf Muller; Daniel Alvarez Sanchez Subject: [All][Neutron][Devstack] OVN as the Default Devstack Neutron Backend
Hi,
The Neutron team wants to propose a switch of the default Neutron backend in Devstack from OVS (neutron-ovs-agent, neutron-dhcp-agent, neutron-l3-agent) to OVN with its own ovn-metadata-agent and ovn-controller. We discussed that change during the virtual PTG - see [1]. In this document we want to explain reasons why we want to do that change.
OVN in 75 Words ---------------
Open Virtual Network is managed under the OVS project, and was created by the original authors of OVS. It is an attempt to re-do the ML2/OVS control plane, using lessons learned throughout the years. It is intended to be used in projects such as OpenStack and Kubernetes. OVN has a different architecture, moving us away from Python agents communicating with the Neutron API service via RabbitMQ to C daemons communicating via OpenFlow and OVSDB.
Here’s a heap of information about OpenStack’s integration of OVN: * OpenStack Boston Summit talk on OVN [2] * Upstream OpenStack networking-ovn documentation [3] and [4] * OSP 13 OVN documentation, including how to install it using Director [5]
Neutron OVN driver was developed as a Neutron stadium project, "networking-ovn". In the Ussuri cycle, networking-ovn was merged into the main Neutron repository.
Why? ----
In the Neutron team we believe that OVN and the Neutron OVN driver are built with a modern architecture that offers better foundations for a simpler and more performant solution. We see increased participation in kubernetes-ovn, resulting in a larger core OVN community, and we would like OpenStack to benefit from this Kubernetes driven OVN investment. Neutron OVN driver currently has got some feature parity gaps comparing to ML2/OVS (see [6] for details) but our team is working hard to close those gaps and we believe that this driver is the future for Neutron and that’s why we want to make it the default Neutron ML2 backend in the Devstack configuration.
What Does it Mean? ------------------
Since most Openstack projects use Neutron in their CI and gate jobs, this change has the potential for a large impact. But this backend is already tested with various jobs in the Neutron CI and it works fine. Recently (See [7]) we also proposed to add an OVN based job to the Devstack’s check queue. Similarly the default Neutron backend in TripleO was changed in the Stein cycle and there were no any significant issues related strictly to this change. It worked well for other projects. Of course in the Neutron project we will be still gating other drivers, like ML2/Linuxbridge and ML2/OVS - nothing will change here, except for the names of some of the jobs. The Neutron team is *NOT* going to deprecate any of the other existing ML2 drivers. We will be still maintaining Linuxbridge, OVS and other in-tree drivers in the same way as it is now.
Action Plan -----------
We want to make this change before the Victoria-2 milestone to not make such changes too late in the release cycle. Our action plan is as below:
1. Share the plan and get feedback from the upstream community (this thread) 2. Move OVN related Devstack code from a plugin defined in the Neutron repo to Devstack repo - we don’t want to force everyone else to add “enable_plugin neutron” in their local.conf file to use default Neutron backend, 3. Switch default Neutron backend in Devstack to be OVN, a. Switch definition of base devstack CI jobs that it will run Neutron with OVN backend, 4. Propose DNM patches depend on patch from point 3 and 3a to main OpenStack projects to check if it will not break anything in the gate of those projects. 5. If all will be running fine, merge patches proposed in points 3 and 3a.
[1] https://etherpad.opendev.org/p/neutron-victoria-ptg - Lines 185 - 193 [2] https://www.youtube.com/watch?v=sgc7myiX6ts [3] https://docs.openstack.org/neutron/latest/admin/ovn/index.html [4] https://docs.openstack.org/neutron/latest/ovn/index.html [5] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/... [6] https://docs.openstack.org/neutron/latest/ovn/gaps.html [7] https://review.opendev.org/#/c/736021/
-- Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Principal software engineer Red Hat
On Tue, Jun 23, 2020 at 3:32 AM Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
The Neutron team wants to propose a switch of the default Neutron backend in Devstack from OVS (neutron-ovs-agent, neutron-dhcp-agent, neutron-l3-agent) to OVN with its own ovn-metadata-agent and ovn-controller. We discussed that change during the virtual PTG - see [1]. In this document we want to explain reasons why we want to do that change.
OVN in 75 Words ---------------
Open Virtual Network is managed under the OVS project, and was created by the original authors of OVS. It is an attempt to re-do the ML2/OVS control plane, using lessons learned throughout the years. It is intended to be used in projects such as OpenStack and Kubernetes. OVN has a different architecture, moving us away from Python agents communicating with the Neutron API service via RabbitMQ to C daemons communicating via OpenFlow and OVSDB.
Here’s a heap of information about OpenStack’s integration of OVN: * OpenStack Boston Summit talk on OVN [2] * Upstream OpenStack networking-ovn documentation [3] and [4] * OSP 13 OVN documentation, including how to install it using Director [5]
Neutron OVN driver was developed as a Neutron stadium project, "networking-ovn". In the Ussuri cycle, networking-ovn was merged into the main Neutron repository.
Why? ----
In the Neutron team we believe that OVN and the Neutron OVN driver are built with a modern architecture that offers better foundations for a simpler and more performant solution. We see increased participation in kubernetes-ovn, resulting in a larger core OVN community, and we would like OpenStack to benefit from this Kubernetes driven OVN investment. Neutron OVN driver currently has got some feature parity gaps comparing to ML2/OVS (see [6] for details) but our team is working hard to close those gaps and we believe that this driver is the future for Neutron and that’s why we want to make it the default Neutron ML2 backend in the Devstack configuration.
What Does it Mean? ------------------
Since most Openstack projects use Neutron in their CI and gate jobs, this change has the potential for a large impact. But this backend is already tested with various jobs in the Neutron CI and it works fine. Recently (See [7]) we also proposed to add an OVN based job to the Devstack’s check queue. Similarly the default Neutron backend in TripleO was changed in the Stein cycle and there were no any significant issues related strictly to this change. It worked well for other projects. Of course in the Neutron project we will be still gating other drivers, like ML2/Linuxbridge and ML2/OVS - nothing will change here, except for the names of some of the jobs. The Neutron team is *NOT* going to deprecate any of the other existing ML2 drivers. We will be still maintaining Linuxbridge, OVS and other in-tree drivers in the same way as it is now.
Action Plan -----------
We want to make this change before the Victoria-2 milestone to not make such changes too late in the release cycle. Our action plan is as below:
1. Share the plan and get feedback from the upstream community (this thread) 2. Move OVN related Devstack code from a plugin defined in the Neutron repo to Devstack repo - we don’t want to force everyone else to add “enable_plugin neutron” in their local.conf file to use default Neutron backend, 3. Switch default Neutron backend in Devstack to be OVN, a. Switch definition of base devstack CI jobs that it will run Neutron with OVN backend, 4. Propose DNM patches depend on patch from point 3 and 3a to main OpenStack projects to check if it will not break anything in the gate of those projects.
+1 This plan looks great. We test Neutron integration quite a bit in OpenStack Manila devstack jobs and in third party CI associated with the project. We've tested OVN in the past and noticed it made share server provisioning faster and more reliable. So I don't think we would be affected negatively should you change the default mechanism and driver. However, please keep us in mind, and perhaps alert me when you post patches so we can test everything is okay.
5. If all will be running fine, merge patches proposed in points 3 and 3a.
[1] https://etherpad.opendev.org/p/neutron-victoria-ptg - Lines 185 - 193 [2] https://www.youtube.com/watch?v=sgc7myiX6ts [3] https://docs.openstack.org/neutron/latest/admin/ovn/index.html [4] https://docs.openstack.org/neutron/latest/ovn/index.html [5] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/... [6] https://docs.openstack.org/neutron/latest/ovn/gaps.html [7] https://review.opendev.org/#/c/736021/
-- Slawek Kaplonski Senior software engineer Red Hat
Hi,
On 8 Jul 2020, at 02:18, Goutham Pacha Ravi <gouthampravi@gmail.com> wrote:
On Tue, Jun 23, 2020 at 3:32 AM Slawek Kaplonski <skaplons@redhat.com> wrote: Hi,
The Neutron team wants to propose a switch of the default Neutron backend in Devstack from OVS (neutron-ovs-agent, neutron-dhcp-agent, neutron-l3-agent) to OVN with its own ovn-metadata-agent and ovn-controller. We discussed that change during the virtual PTG - see [1]. In this document we want to explain reasons why we want to do that change.
OVN in 75 Words ---------------
Open Virtual Network is managed under the OVS project, and was created by the original authors of OVS. It is an attempt to re-do the ML2/OVS control plane, using lessons learned throughout the years. It is intended to be used in projects such as OpenStack and Kubernetes. OVN has a different architecture, moving us away from Python agents communicating with the Neutron API service via RabbitMQ to C daemons communicating via OpenFlow and OVSDB.
Here’s a heap of information about OpenStack’s integration of OVN: * OpenStack Boston Summit talk on OVN [2] * Upstream OpenStack networking-ovn documentation [3] and [4] * OSP 13 OVN documentation, including how to install it using Director [5]
Neutron OVN driver was developed as a Neutron stadium project, "networking-ovn". In the Ussuri cycle, networking-ovn was merged into the main Neutron repository.
Why? ----
In the Neutron team we believe that OVN and the Neutron OVN driver are built with a modern architecture that offers better foundations for a simpler and more performant solution. We see increased participation in kubernetes-ovn, resulting in a larger core OVN community, and we would like OpenStack to benefit from this Kubernetes driven OVN investment. Neutron OVN driver currently has got some feature parity gaps comparing to ML2/OVS (see [6] for details) but our team is working hard to close those gaps and we believe that this driver is the future for Neutron and that’s why we want to make it the default Neutron ML2 backend in the Devstack configuration.
What Does it Mean? ------------------
Since most Openstack projects use Neutron in their CI and gate jobs, this change has the potential for a large impact. But this backend is already tested with various jobs in the Neutron CI and it works fine. Recently (See [7]) we also proposed to add an OVN based job to the Devstack’s check queue. Similarly the default Neutron backend in TripleO was changed in the Stein cycle and there were no any significant issues related strictly to this change. It worked well for other projects. Of course in the Neutron project we will be still gating other drivers, like ML2/Linuxbridge and ML2/OVS - nothing will change here, except for the names of some of the jobs. The Neutron team is *NOT* going to deprecate any of the other existing ML2 drivers. We will be still maintaining Linuxbridge, OVS and other in-tree drivers in the same way as it is now.
Action Plan -----------
We want to make this change before the Victoria-2 milestone to not make such changes too late in the release cycle. Our action plan is as below:
1. Share the plan and get feedback from the upstream community (this thread) 2. Move OVN related Devstack code from a plugin defined in the Neutron repo to Devstack repo - we don’t want to force everyone else to add “enable_plugin neutron” in their local.conf file to use default Neutron backend, 3. Switch default Neutron backend in Devstack to be OVN, a. Switch definition of base devstack CI jobs that it will run Neutron with OVN backend, 4. Propose DNM patches depend on patch from point 3 and 3a to main OpenStack projects to check if it will not break anything in the gate of those projects.
+1 This plan looks great. We test Neutron integration quite a bit in OpenStack Manila devstack jobs and in third party CI associated with the project. We've tested OVN in the past and noticed it made share server provisioning faster and more reliable. So I don't think we would be affected negatively should you change the default mechanism and driver. However, please keep us in mind, and perhaps alert me when you post patches so we can test everything is okay.
We will for sure alert others to check this in their project when it will be ready. For now Lucas is still working on patches to move ovn bits to the Devstack repo.
5. If all will be running fine, merge patches proposed in points 3 and 3a.
[1] https://etherpad.opendev.org/p/neutron-victoria-ptg - Lines 185 - 193 [2] https://www.youtube.com/watch?v=sgc7myiX6ts [3] https://docs.openstack.org/neutron/latest/admin/ovn/index.html [4] https://docs.openstack.org/neutron/latest/ovn/index.html [5] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/... [6] https://docs.openstack.org/neutron/latest/ovn/gaps.html [7] https://review.opendev.org/#/c/736021/
-- Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Principal software engineer Red Hat
participants (6)
-
Assaf Muller
-
Carlos Goncalves
-
Goutham Pacha Ravi
-
Radosław Piliszek
-
Slawek Kaplonski
-
Tobias Urdin