[openstack-dev] [keystone] re-ordering of schema migrations

Mark McLoughlin markmc at redhat.com
Wed Feb 27 13:43:49 UTC 2013


On Wed, 2013-02-27 at 08:09 -0500, Eoghan Glynn wrote:
> Folks,
> 
> When looking into an error encountered on a keystone db sync,
> I noticed some apparent strangeness in the way keystone schema
> migrations have been managed.
> 
> Specifically the *rewriting* of schema migration history, see:
> 
>   https://github.com/openstack/keystone/commit/5bc46d86
> 
> In my (albeit imperfect) understanding of sqlalchemy-migrate, this
> reordering seems to defeat the whole purpose of step-wise reversible
> migration.
> 
> Would it even be possible to migrate a grizzly-2 deployment to
> grizzly-3 with that re-ordering in place? 
> 
> Maybe I've missed something here, but I'd appreciate some clarity
> on what is considered community best practice in terms of changes
> to the migration sequence.
> 
> Previously I would have assumed something like ...
> 
> Invariants we maintain:
> 
>  - DB schemas must always be migrate-able across milestone releases

(snip good stuff)

It's more than just across milestone releases, we should support
upgrading from commit to commit. In Nova, at least, we're trying hard to
avoid messing up those who are deploying continuously. I'd expect any
nova-core member to reject this patch immediately.

What I really don't understand is how this concern wasn't raised in the
review at all:

  https://review.openstack.org/19780

Cheers,
Mark.




More information about the OpenStack-dev mailing list