[openstack-dev] [DB][Migrations] Switching to using of Alembic
dolph.mathews at gmail.com
Tue Jul 16 17:02:16 UTC 2013
On Tue, Jul 16, 2013 at 11:53 AM, Doug Hellmann <doug.hellmann at dreamhost.com
> On Tue, Jul 16, 2013 at 11:51 AM, Roman Podolyaka <rpodolyaka at mirantis.com
> > wrote:
>> Hello, stackers!
>> Most of you who is interested in work around DB in OpenStack must have
>> read this thread  started by Boris Pavlovic. Boris made an overview of
>> the work our team is doing to make DB code better.
>> One of our main goals is to switch from sqlalchemy-migrate to Alembic for
>> applying of DB schema migrations. sqlalchemy-migrate was abandoned for a
>> long time, and even now when it's become adopted by OpenStack community,
>> we'd better use a project which is supported by upstream (especially in the
>> case when the author of this project is the same person who also authored
>> The switch isn't going to be simple though. We have a few problems:
>> 1) stable releases must be supported for some time, so we can't switch
>> from migrate to alembic immediately
>> The switch should probably be made when previous migrations scripts are
>> "compacted", so all new migrations scripts will use alembic. Switching of
>> such big projects as Nova is hard, so we decided to gain some experience
>> with porting of smaller ones first. Alexei Kornienko is currently working
>> on adding support of Alembic migrations in Ceilometer .
> I like the idea of switching when we do a major release. I don't think we
> need to port the old migrations to alembic, though, as I said to Alexei on
> the review. We should be able to continue to have sqlalchemy-migrate
> distributed as part of OpenStack for the legacy migrations until those
> migrations can be dropped entirely. Updating would mean running
> sqlalchemy-migrate, and then alembic, to apply the full set of migrations.
> From what I understand the policy to be, since we have sqlalchemy-migrate
> scripts in Havana we could stop creating new ones in Icehouse and drop the
> use of sqlalchemy-migrate entirely in the J release when the Havana
> migrations are removed.
This would be my preferred approach as well.
>> Our long term goal is to switch all projects from using of
>> sqlalchemy-migrate to Alembic.
>> 2) we rely on schema migrations to set up an SQLite database for running
>> Nova and possibly other projects use schema migrations to set up an
>> SQLite database for running tests. Unfortunately, we can't use models
>> definitions for generation of initial DB schema, because those definitions
>> do not correspond migration scripts. Our team is working on fixing of this
>> issue .
>> As you may now SQLite has limited support of ALTER DDL statements .
>> Nova code contains a few auxiliary functions to make ALTER work in SQLite.
>> Unfortunately, Alembic doesn't support ALTER in SQLite on purpose . In
>> order to run our tests on SQLite right now using Alembic as a schema
>> migration tool, we should add ALTER support to it first.
>> We are going to implement ALTER support in Alembic for SQLite in the next
>> few weeks.
>> As always, your comments in ML and reviews are always welcome.
>>  http://www.sqlite.org/lang_altertable.html
>>  https://bitbucket.org/zzzeek/alembic
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev