On 4/6/15 12:06 PM, Clint Byrum wrote:
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.
The standard approach here is that tests based on the oslo.db approach
by default connect using a username openstack_citest on localhost, which
is then used to create databases of random names. If you base your
database tests on oslo.db, you get that right now. This
username/host/etc is also configurable through environment variables. I
don't see how my.cnf is involved in this nor how it would impact
someone's keystone database, unless we're talking about tests that
happen to load down and/or crash the whole database server.
spinning up a whole mysqld seems really heavy-handed and unnecessary.
Not to mention the tests run on other backends as well such as Postgresql.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
