[openstack-dev] [Keystone] Cockroachdb for Keystone Multi-master
serverascode at gmail.com
Thu May 18 23:43:39 UTC 2017
On Thu, May 18, 2017 at 4:13 PM, Adrian Turjak <adriant at catalyst.net.nz> wrote:
> Hello fellow OpenStackers,
> For the last while I've been looking at options for multi-region
> multi-master Keystone, as well as multi-master for other services I've
> been developing and one thing that always came up was there aren't many
> truly good options for a true multi-master backend. Recently I've been
> looking at Cockroachdb and while I haven't had the chance to do any
> testing I'm curious if anyone else has looked into it. It sounds like
> the perfect solution, and if it can be proved to be stable enough it
> could solve a lot of problems.
> So, specifically in the realm of Keystone, since we are using sqlalchemy
> we already have Postgresql support, and since Cockroachdb does talk
> Postgres it shouldn't be too hard to back Keystone with it. At that
> stage you have a Keystone DB that could be multi-region, multi-master,
> consistent, and mostly impervious to disaster. Is that not the holy
> grail for a service like Keystone? Combine that with fernet tokens and
> suddenly Keystone becomes a service you can't really kill, and can
> mostly forget about.
> I'm welcome to being called mad, but I am curious if anyone has looked
> at this. I'm likely to do some tests at some stage regarding this,
> because I'm hoping this is the solution I've been hoping to find for
> quite a long time.
I was going to take a look at this a bit myself, just try it out. I
can't completely speak for the Fog/Edge/Massively Distributed working
group in OpenStack, but I feel like this might be something they look
For standard multi-site I don't know how much it would help, say if
you only had a couple or three clouds, but more than that maybe this
starts to make sense. Also running Galera has gotten easier but still
not that easy.
I had thought that the OpenStack community was deprecating Postgres
support though, so that could make things a bit harder here (I might
be wrong about this).
> Further reading:
> - Adrian Turjak
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev