Open Stack

On Tue, Jun 23, 2020 at 3:32 AM 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.
>

+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/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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200707/8d37930b/attachment-0001.html>