<div dir="ltr"><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg">If I propose some concrete solution that will be discussion about one solution not about making things flexible.</div><div dir="ltr" class="gmail_msg">At first I wanted to propose some PoC for other approach, but during my experiments I understood that we may have different approaches, but for all of them we need pluggable HA router in Neutron.</div><br class="gmail_msg">The thing that bothers me about L3 HA - it is complex. Yes, we fixed bunch of races and John did significant refactor, but it is still too complex. In the end we want to use L3 HA + DVR but DVR is pretty complex by itself. We would like to try to offload this complexity to external service to replace management of keepalived instances and networks withing Neutron. Router rescheduling is not really an alternative for L3 HA.</div><div dir="ltr" class="gmail_msg"><br>RDO with L3 HA is a great example of success, but we want to have ability to try something else that can suit other OpenStack deployments better.<br><br></div><div class="gmail_msg">I wrote this email to understand whether community have interest in something like this, so that it will be worth doing.   </div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Feb 14, 2017 at 10:20 PM Assaf Muller <<a href="mailto:assaf@redhat.com" class="gmail_msg" target="_blank">assaf@redhat.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Feb 10, 2017 at 12:27 PM, Anna Taraday<br class="gmail_msg">
<<a href="mailto:akamyshnikova@mirantis.com" class="gmail_msg" target="_blank">akamyshnikova@mirantis.com</a>> wrote:<br class="gmail_msg">
> Hello everyone!<br class="gmail_msg">
><br class="gmail_msg">
> In Juno in Neutron was implemented L3 HA feature based on Keepalived (VRRP).<br class="gmail_msg">
> During next cycles it was improved, we performed scale testing [1] to find<br class="gmail_msg">
> weak places and tried to fix them. The only alternative for L3 HA with VRRP<br class="gmail_msg">
> is router rescheduling performed by Neutron server, but it is significantly<br class="gmail_msg">
> slower and depends on control plane.<br class="gmail_msg">
><br class="gmail_msg">
> What issues we experienced with L3 HA VRRP?<br class="gmail_msg">
><br class="gmail_msg">
> Bugs in Keepalived (bad versions) [2]<br class="gmail_msg">
> Split brain [3]<br class="gmail_msg">
> Complex structure (ha networks, ha interfaces) - which actually cause races<br class="gmail_msg">
> that we were fixing during Liberty, Mitaka and Newton.<br class="gmail_msg">
><br class="gmail_msg">
> This all is not critical, but this is a bad experience and not everyone<br class="gmail_msg">
> ready (or want) to use Keepalived approach.<br class="gmail_msg">
><br class="gmail_msg">
> I think we can make things more flexible. For example, we can allow user to<br class="gmail_msg">
> use external services like etcd instead of Keepalived to synchronize current<br class="gmail_msg">
> HA state across agents. I've done several experiments and I've got failover<br class="gmail_msg">
> time comparable to L3 HA with VRRP. Tooz [4] can be used to abstract from<br class="gmail_msg">
> concrete backend. For example, it can allow us to use Zookeeper, Redis and<br class="gmail_msg">
> other backends to store HA state.<br class="gmail_msg">
><br class="gmail_msg">
> What I want to propose?<br class="gmail_msg">
><br class="gmail_msg">
> I want to bring up idea that Neutron should have some general classes for L3<br class="gmail_msg">
> HA which will allow to use not only Keepalived but also other backends for<br class="gmail_msg">
> HA state. This at least will make it easier to try some other approaches and<br class="gmail_msg">
> compare them with existing ones.<br class="gmail_msg">
><br class="gmail_msg">
> Does this sound reasonable?<br class="gmail_msg">
<br class="gmail_msg">
I understand that the intention is to add pluggability upstream so<br class="gmail_msg">
that you could examine the viability of alternative solutions. I'd<br class="gmail_msg">
advise instead to do the research locally, and if you find concrete<br class="gmail_msg">
benefits to an alternative solution, come back, show your work and<br class="gmail_msg">
have a discussion about it then. Merging extra complexity in the form<br class="gmail_msg">
of a plug point without knowing if we're actually going to need it<br class="gmail_msg">
seems risky.<br class="gmail_msg">
<br class="gmail_msg">
On another note, after years of work the stability issues have largely<br class="gmail_msg">
been resolved and L3 HA is in a good state with modern releases of<br class="gmail_msg">
OpenStack. It's not a authoritative solution in the sense that it<br class="gmail_msg">
doesn't cover every possible failure mode, but it covers the major<br class="gmail_msg">
ones and in that sense better than not having any form of HA, and as<br class="gmail_msg">
you pointed out the existing alternatives are not in a better state.<br class="gmail_msg">
The subtext in your email is that now L3 HA is technically where we<br class="gmail_msg">
want it, but some users are resisting adoption because of bad PR or a<br class="gmail_msg">
bad past experience, but not for technical reasons. If that is the<br class="gmail_msg">
case, then perhaps some good PR would be a more cost effective<br class="gmail_msg">
investment than investigating, implementing, stabilizing and<br class="gmail_msg">
maintaining a different backend that will likely take at least a cycle<br class="gmail_msg">
to get merged and another 1 to 2 cycles to iron out kinks. Would you<br class="gmail_msg">
have a critical mass of developers ready to support a pluggable L3 HA<br class="gmail_msg">
now and in the long term?<br class="gmail_msg">
<br class="gmail_msg">
Finally, I can share that L3 HA has been the default in RDO-land for a<br class="gmail_msg">
few cycles now and is being used widely and successfully, in some<br class="gmail_msg">
cases at significant scale.<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> [1] -<br class="gmail_msg">
> <a href="http://docs.openstack.org/developer/performance-docs/test_results/neutron_features/index.html" rel="noreferrer" class="gmail_msg" target="_blank">http://docs.openstack.org/developer/performance-docs/test_results/neutron_features/index.html</a><br class="gmail_msg">
> [2] - <a href="https://bugs.launchpad.net/neutron/+bug/1497272" rel="noreferrer" class="gmail_msg" target="_blank">https://bugs.launchpad.net/neutron/+bug/1497272</a><br class="gmail_msg">
> <a href="https://bugs.launchpad.net/neutron/+bug/1433172" rel="noreferrer" class="gmail_msg" target="_blank">https://bugs.launchpad.net/neutron/+bug/1433172</a><br class="gmail_msg">
> [3] - <a href="https://bugs.launchpad.net/neutron/+bug/1375625" rel="noreferrer" class="gmail_msg" target="_blank">https://bugs.launchpad.net/neutron/+bug/1375625</a><br class="gmail_msg">
> [4] - <a href="http://docs.openstack.org/developer/tooz/" rel="noreferrer" class="gmail_msg" target="_blank">http://docs.openstack.org/developer/tooz/</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> --<br class="gmail_msg">
> Regards,<br class="gmail_msg">
> Ann Taraday<br class="gmail_msg">
><br class="gmail_msg">
> __________________________________________________________________________<br class="gmail_msg">
> OpenStack Development Mailing List (not for usage questions)<br class="gmail_msg">
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="gmail_msg" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="gmail_msg">
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
__________________________________________________________________________<br class="gmail_msg">
OpenStack Development Mailing List (not for usage questions)<br class="gmail_msg">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="gmail_msg" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="gmail_msg">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="gmail_msg">
</blockquote></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">Regards,<br>Ann Taraday</div></div>