Open Stack

Folks

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.

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.

On Mon, Aug 3, 2015 at 4:10 PM, Lance Bragstad <lbragstad at gmail.com> wrote:

>
>
> On Mon, Aug 3, 2015 at 7:03 AM, David Stanek <dstanek at dstanek.com> wrote:
>
>>
>> On Mon, Aug 3, 2015 at 7:14 AM, Davanum Srinivas <davanum at gmail.com>
>> wrote:
>>
>>> agree. "Native HA solution" was already ruled out in several email
>>> threads by keystone cores already (if i remember right). This is a
>>> devops issue and should be handled as such was the feedback.
>>>
>>
>> I'm sure you are right. I'm not sure why we would want to add that much
>> complexity into Keystone.
>>
>
> ++, 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.
>
>>
>>
>>
>> --
>> David
>> blog: http://www.traceback.org
>> twitter: http://twitter.com/dstanek
>> www: http://dstanek.com
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150803/dfc800f1/attachment.html>