Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev