Open Stack

Hi,

Bump. Anyone has got any thoughts about it?

> On 23 Jun 2020, at 12:24, Slawek Kaplonski <skaplons at 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/html/networking_with_open_virtual_network/
> [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