[openstack-dev] [keystone] sqlite doesn't support migrations
ayoung at redhat.com
Wed Jul 17 17:40:06 UTC 2013
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
> 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?
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
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 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.
More information about the OpenStack-dev