Open Stack

On 07/16/2013 10:58 AM, Thomas Goirand wrote:
> On 07/16/2013 03:55 PM, Michael Still wrote:
>> On Tue, Jul 16, 2013 at 4:17 PM, Thomas Goirand <zigo at debian.org> wrote:
>>
>>> Could you explain a bit more what could be done to fix it in an easy
>>> way, even if it's not efficient? I understand that ALTER doesn't work
>>> well. Though would we have the possibility to just create a new
>>> temporary table with the correct fields, and copy the existing content
>>> in it, then rename the temp table so that it replaces the original one?
>> There are a bunch of nova migrations that already work that way...
>> Checkout the *sqlite* files in
>> nova/db/sqlalchemy/migrate_repo/versions/
> Why can't we do that with Keystone then? Is it too much work? It doesn't
> seem hard to do (just probably a bit annoying and boring ...). Does it
> represent too much work for the case of Keystone?
>
> Thomas
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
In general, yes, the SQlite migrations have eaten up far more time than 
the benefit they provide.

Sqlite migrations don't buy us much.  A live deployment should not be on 
sqlite.  It is OK to use it for testing, though.  As such, it should be 
possible to generate a sqlite scheme off the model the way that the unit 
tests do.  You just will not be able to migrate it forward:  later 
changes will require regenerating the database.

For any non-trivial deployent, we should encourage the use of Mysql or 
Postgresql.  Migrations for these will be full supported.

 From a unit test perspective, we are going to disable the sqlite 
migration tests.  Users that need to perform testing of migrations 
should instead test them against both mysql and postgresql. the IBMers 
out there will also be responsible for keeping on top of the DB2 
variations.  The [My/postgre]Sql migration tests will be run as part of 
the gate.

The current crop of unit tests for the SQL backend use the module based 
approach to generate a sqlite database.  This approach is fine.  Sqlite, 
when run in memory, provides a very fast sanity check of our logic.  
MySQL and PostgreSQL versions would take far, far too long to execute 
for everyday development. We will, however, make it possible to execute 
those body of unit tests against both postgresql and mysql as part of 
the gate.  Wer will also execute against the LDAP backend.  IN order to 
be able to perform that, however, we need to fix bunch of the tests so 
that they run at 100% first.