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