<div dir="ltr">Folks<div><br></div><div>As Sergii G. already pointed out if you want this solution to work in production, you should provide common ways of synchronization between different processing entities. Otherwise your "very simple one-script solution" will be prone to errors such as race conditions and others. You need to have a consensus and leader election algorithms here embedded into keystone. Moreover, this process should be as realtime as possible and this means, sticking to eventlet library is not the best option here.</div><div><br></div><div>So I am +1 to Bogdan and Pacemaker-based solution as it is just a simple master/slave resource which will run on top of already implemented and well-tested cluster stack. It is not so hard to debug such pacemaker scripts, actually, so I cannot agree with those who say, that this scheme is over-complicated. Either write your own implementation of cluster algorithms or go with existing cluster stack. Having "simple script" will just make your production fail eventually.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 3, 2015 at 4:10 PM, Lance Bragstad <span dir="ltr"><<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Aug 3, 2015 at 7:03 AM, David Stanek <span dir="ltr"><<a href="mailto:dstanek@dstanek.com" target="_blank">dstanek@dstanek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span><br><div class="gmail_quote">On Mon, Aug 3, 2015 at 7:14 AM, Davanum Srinivas <span dir="ltr"><<a href="mailto:davanum@gmail.com" target="_blank">davanum@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="overflow:hidden">agree. "Native HA solution" was already ruled out in several email<br>
threads by keystone cores already (if i remember right). This is a<br>
devops issue and should be handled as such was the feedback.</div></blockquote></div><br></span>I'm sure you are right. I'm not sure why we would want to add that much complexity into Keystone.</div></div></blockquote><div><br></div></span><div>++, I think the more complicated the tool to distribute the keys, the more complex it is to troubleshoot issues when things go south. If you have an issue with a single Keystone node, you have to understand whatever mechanism that keeps keys in sync, as well as what could go wrong and how to fix it. This is in comparison to something, or some ansible script, that is idempotent and can be applied against the whole cluster, or a single node. The ability of having a staged key buys you time in the key distribution process. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="ltr"><div class="gmail_extra"><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>David<br>blog: <a href="http://www.traceback.org" target="_blank">http://www.traceback.org</a><br>twitter: <a href="http://twitter.com/dstanek" target="_blank">http://twitter.com/dstanek</a><div>www: <a href="http://dstanek.com" target="_blank">http://dstanek.com</a></div></div>
</font></span></div></div>
<br></span><span class="">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></span></blockquote></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>