Open Stack

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

 - migrations must be structurally reversible, but not necessarily
   data-preserving

Inadvisable changes:

 - re-ordering of migration indices
 
 - mods to *existing* scripts that could cause later migrations to
   fail (ruling out pretty much any structural change)

Acceptable changes:

 - consolidation of adjacent scripts, coinciding with major releases
   (as per the nova practice over the last couple cycles)

 - trivial mods to existing scripts that do not result in structural
   change

Cheers,
Eoghan