Open Stack

On 05/22/2017 05:02 AM, Thierry Carrez wrote:
> 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".
>> [...]
> Yes, that sounds like another reason why we'd not want to aggressively
> contract to the MySQL family of databases. At the very least, before we
> do that, we should experiment with CockroachDB and see how reasonable it
> would be to use in an OpenStack context. It might (might) hit a sweet
> spot between performance, durability, database decentralization and
> keeping SQL advanced features -- I'd hate it if we discovered that too late.

there's a difference between "architecting for pluggability" and 
"supporting database X, Y, and Z".   I only maintain we should keep the 
notion of pluggability around.  This doesn't mean you can't use MySQL 
specific features, it only means, anytime you're using a MySQL feature, 
it's in the context of a unit of code that would be swapped out when a 
different database backend were to be implemented.   The vast majority 
of our database code is like this already, mostly implicitly due to 
SQLAlchemy and in other cases explicitly as we see in a lot of the 
migration scripts.

I think the existence of the PG backend, combined with the immediate 
interest in getting NDB to work, and now Cockroach DB, not to mention 
that there are two major MySQL variants (MySQL, MariaDB) which do have 
significant differences (the JSON type one of the biggest examples) 
should suggest that any modern database-enabled application can't really 
afford to completely hardcode to a single database backend without at 
least basic layers of abstraction being present.	

>