Open Stack

On 20/05/17 09:31, Mike Bayer wrote:
>
> On 05/18/2017 06:13 PM, Adrian Turjak wrote:
>>
>> 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.
>
> So this is exhibit A for why I think keeping some level of "this might
> need to work on other databases" within a codebase is always a great
> idea even if you are not actively supporting other DBs at the moment.
> Even if Openstack dumped Postgresql completely, I'd not take the
> rudimental PG-related utilities out of oslo.db nor would I rename all
> the "mysql_XYZ" facilities to be "XYZ".
I have posted on the reviews, but my hope is that if we do drop
PostgreSQL support we at least also state that we will not support any
database specific features that preclude someone from using/supporting a
different database should they wish to, and that we will not deny
patches that add/fix support for other databases provided they do not
interfere with support for the ones we do 'support' officially.
>
> Cockroachdb advertises SQLAlchemy compatibility very prominently. 
> While their tutorial at
> https://www.cockroachlabs.com/docs/build-a-python-app-with-cockroachdb-sqlalchemy.html
> says it uses psycopg2 as the database driver, they have implemented
> their own "cockroachdb://" dialect on top of it, which likely smooths
> out the SQL dialect and connectivity quirks between real Postgresql
> and CockroachDB.
>
> This is not the first "distributed database" to build on the
> Postgresql protocol, I did a bunch of work for a database that started
> out called "Akiban", then got merged to "FoundationDB", and then sadly
> was sucked into a black hole shaped like a huge Apple and the entire
> product and staff were gone forever.  CockroachDB seems to be filling
> in that same hole that I was hoping FoundationDB was going to do
> (until they fell into said hole).
>
>>
>> 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'd have a blast if Keystone wanted to get into this.   Distributed /
> NewSQL is something I have a lot of optimism about.   Please keep me
> looped in.
>

I can't speak for the Keystone team itself, this was mainly my own
speculation and general ideas about how to better handle
multi-master/DR. I know that standard MySQL async mult-master would work
for a lot of cases, but async multi-master has a bunch of problems that
are often very weird, rare, or painful and hard to debug so people tend
to avoid it unless there is no other option.  That's why I have a lot of
interest in CockroachDB because it was built pretty much entirely to
solve just that case in the Google Spanner mold.

The scenario I'm interested with this is Keystone setup for Fernet
tokens, multi-site, multi-master, and geo-loadbalancing so you always
talk to your nearest datacenter. With non-admin users being able to self
manage their own projects, users, and roles within some scope. Thus data
needs to be consistent across regions because of DR and
geo-loadbalancing, but also you may have multiple people editing the
same users at the same time in different places. I'm curious how much
better Cockroachdb may handle those cases, but from the looks of things
a lot of those problems aren't there or only crop up in very large or
complex transactions which Keystone doesn't seem to have too many of (I
could be wrong though). My use case likely isn't going to hit many
problems with multi-master since we are currently only running 3 sites
that share auth, but I prefer to plan for worst case scenario! Plus the
more I can trust the DB layer, the more I can focus elsewhere.