Open Stack

Thanks Matt. That surely is helpful. If you could share some numbers or
problems you faced when you were storing UUID tokens in database, it would
be awesome. In my test setup with Keystone Kilo, Fernet token creation and
validation were way slower than UUID tokens. But UUID tokens come with a
huge cost to database which is the pain point. I have never run Keystone
with UUID tokens in Prod setup. So I am looking for perspective on Keystone
with UUID in prod setup.

Thanks to other people who also chimed in with advice.

Cheers,
Ajaya

On Mon, Dec 7, 2015 at 8:34 PM, Matt Fischer <matt at mattfischer.com> wrote:

> On Mon, Dec 7, 2015 at 3:54 AM, Ajaya Agrawal <ajku.agr at gmail.com> wrote:
>
>> Hi everyone,
>>
>> We are deploying Openstack and planning to run multi-master Galera setup
>> in production. My team is responsible for running a highly available
>> Keystone. I have two questions when it comes to Galera with Keystone.
>>
>> 1. How do you test if a Galera cluster is setup properly?
>> 2. Is there any Galera test specific to Keystone which you have found
>> useful?
>>
>>
> For 1 you could say that the clustercheck script which ships with
> puppet-galera and is forked from
> https://github.com/olafz/percona-clustercheck is a really simple check
> that galera is up and the cluster is sync'd. It's main goal however is to
> provide status to haproxy.
>
> One thing you want to check is the turnaround time on operations, for
> example, creating a user on a node and then immediately using them on
> another node. We found that this is likely to sometimes (but rarely) fail.
> The solution is two-fold, first, don't store tokens in mysql. Second,
> designate one node as the primary in haproxy.
>
> Other than that we've gotten good at reading the wsrep_ cluster status
> info, but to be honest, once we removed tokens from the db, we've been in
> way better shape.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151211/3f621c40/attachment.html>