Open Stack

On 03/20/2013 06:14 PM, Michael Still wrote:
> On Thu, Mar 21, 2013 at 9:05 AM, Russell Bryant <rbryant at redhat.com> wrote:
>> Greetings,
>>
>> One of the features we had on the roadmap for Grizzly was the ability to
>> backport DB migrations to stable/grizzly after the release if necessary.
>>   The blueprint became a Havana blueprint, because the implementation
>> turned out to just reserve a range of migrations numbers at the
>> beginning of Havana development.
>>
>>      https://blueprints.launchpad.net/nova/+spec/backportable-db-migrations
>>      https://review.openstack.org/#/c/23759/
>>
>> I wanted to make sure everyone was aware of this when doing reviews of
>> future db migrations.  It means that we must make sure that migrations
>> added for Havana are idempotent.  That way it should be safe to backport
>> them.  When someone upgrades from a stable release that included
>> backportable migrations, they're going to get the same migration again
>> at a higher number.
>
> This sounds reasonable to me. We did talk at the summit about Alembic
> as well, but I'm not sure anyone actually did anything after that. Are
> we still thinking of moving ORM at some point in the future?

I think Alembic is the most reasonable option if we care about 
backportability.  sqlalchemy-migrate's fixed ordering isn't flexible 
enough to support backporting in arbitrary order, for example if a 
downstream OpenStack provider wants to apply some critical bugfixes but 
not other changes to their version of a stable OpenStack tree.  Also, it 
would be nice to have some migrations always come last -- I'm thinking 
in particular of nova's 154_add_shadow_tables which looks at all 
existing tables and adds "shadow_" versions, but we may have others like 
that in the future.

I wrote a script to convert our migrate scripts to Alembic a few months 
ago, though it only did about 90% of the job, and the last 10% would be 
a bit painful.  We've added more migrations since then.  Of course, the 
conversion from migrate to Alembic would be more difficult to reverse 
than other migrations.  https://review.openstack.org/#/c/15196/

Any serious rework of our migrations needs to go through 
https://wiki.openstack.org/wiki/Database_migration_testing

-- 
David Ripton   Red Hat   dripton at redhat.com