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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
