Open Stack

On Thu, Jul 9, 2020 at 11:45 AM Slawek Kaplonski <skaplons at redhat.com>
wrote:

> Hi,
>
> Thx for Your feedback.
>
> > On 6 Jul 2020, at 11:49, Tobias Urdin <tobias.urdin at 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.html


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