Open Stack

Excerpts from Boris Bobrov's message of 2015-04-03 18:29:08 -0700:
> On Saturday 04 April 2015 03:55:59 Morgan Fainberg wrote:
> > I am looking forward to the Liberty cycle and seeing the special casing we
> > do for SQLite in our migrations (and elsewhere). My inclination is that we
> > should (similar to the deprecation of eventlet) deprecate support for
> > SQLite in Keystone. In Liberty we will have a full functional test suite
> > that can (and will) be used to validate everything against much more real
> > environments instead of in-process “eventlet-like” test-keystone-services;
> > the “Restful test cases” will no longer be part of the standard unit tests
> > (as they are functional testing). With this change I’m inclined to say
> > SQLite (being the non-production usable DB) what it is we should look at
> > dropping migration support for SQLite and the custom work-arounds.
> > 
> > Most deployers and developers (as far as I know) use devstack and MySQL or
> > Postgres to really suss out DB interactions.
> > 
> > I am looking for feedback from the community on the general stance for
> > SQLite, and more specifically the benefit (if any) of supporting it in
> > Keystone.
> 
> +1. Drop it and clean up tons of code used for support of sqlite only.
> 
> Doing tests with mysql is as easy, as with sqlite ("mysqladmin drop -f; 
> mysqladmin create" for "reset"), and using it by default will finally make 
> people test their code on real rdbmses.
> 

Please please please be careful with that and make sure the database
name is _always_ random in tests... or even better, write a fixture to
spin up a mysqld inside a private tempdir. That would be a really cool
thing for oslo.db to provide actually.

I'm just thinking some poor sap runs the test suite with the wrong
.my.cnf in the wrong place and <poof> there went keystone's db.