Open Stack

On Sep 29, 2014, at 7:23 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> 
> >
> >> """ We could also update the release notes indicating that
> >> existing deployments will need to manually modify their schema if
> >> they're already at Icehouse. """ [1]:
> >> https://review.openstack.org/#/c/110642/
> >
> > Hmm, what was the outcome of discussion about backporting db
> > migrations with Alembic? Isn't there a way to insert db migration
> > so that admin could just run neutron-db-manage upgrade ?
> 
> I think there is no way to introduce trees in migration chains until
> the following alembic is implemented and released:
> 
> https://bitbucket.org/zzzeek/alembic/issue/167/multiple-heads-branch-resolution-support
> 
> Mike, is it correct?

You can absolutely insert migrations in the middle of the existing series, that was one of the key design goals of Alembic vs. Migrate.

The issue mentioned above would allow three new things.   The main one is that individual migrations would be run independently of any others except the ones they were dependent on, relative to the state of an particular database.   This means that in the scenario where there are two target databases, where database A was migrated along branch X and database B was migrated along branch Y, could both be made to arrive at merge point Z using the same set of migration files - database A would receive just the Y migrations and database B would receive just the X migrations.   This is the most important aspect of the change, however the case to which this applies is fairly rare, where two databases that hold production data or data that can’t be rebuilt have been migrated along two divergent schema branches, and need to be resolved to a common merge point.   Some of our users have this case going on but I don’t think it typically applies to openstack (but let me know if I’m mistaken there).

The second thing it provides, which is more applicable to openstack, is that the multiple branches can optionally be made to remain independent of each other, so that you can upgrade along branches without impacting the others - this would allow a scenario such as, one branch adds all the new columns and tables to the database, then the app code is upgraded, then another branch is run to remove all the old columns and old tables.    However again, this is something openstack could do in the future to allow migrations with no downtime, but my understanding is that this is not an available feature right now.

Finally, the third feature is that when you do have multiple branches that you want to merge, they can be resolved automatically by adding a merge revision, just like any other VCS, since the migrations don’t have to be manually linked in series.

As it stands right now, Alembic wants to see a single series of revision files, however you can rearrange and mutate this ordering any way you’d like, insertions are not a problem.    As we are targeting systems that are working along a linear release scheme, this should be all we ultimately need.   The resolution of branches is manual but simple, and is documented here: http://alembic.readthedocs.org/en/latest/tutorial.html#working-with-branches.