Open Stack

Previously when there was some confusion over what types of
changes to existing APIs were acceptable without a major version
bump, we ended up with a TC-endorsed set of guidelines to aid
reviewers:

  https://wiki.openstack.org/wiki/APIChangeGuidelines

Perhaps something similar would be useful for DB migrations?

Here's a strawman to kick it off:

  https://wiki.openstack.org/wiki/DbMigrationChangeGuidelines

Please feel free to hack away on it until we get to a community
understanding.

Thanks,
Eoghan


----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Dolph Mathews" <dolph.mathews at gmail.com>
> > To: "Mark McLoughlin" <markmc at redhat.com>, "OpenStack Development
> > Mailing List" <openstack-dev at lists.openstack.org>
> > Sent: Wednesday, February 27, 2013 9:09:00 AM
> > Subject: Re: [openstack-dev] [keystone] re-ordering of schema
> > migrations
> > 
> > This was discussed in #openstack-dev, as I recall.
> > 
> > The goal in these migrations was to support folsom <--> grizzly,
> > not
> > necessarily supporting intermediate milestones. I'm not aware of
> > anyone
> > doing continuous deployments of keystone, if but if migrating
> > commit
> > to
> > commit is the community's expectation, I'm more happy to ensure
> > that
> > happens moving forward -- I just wasn't aware that was a concern
> > here.
> 
> We should always support upgrading between the milestones.
> 
> Also, Existing migrations should never be re-ordered.
> 
> One thing you could do is compact the "released" (as in part of the
> previous stable release) migrations into a single (large) migration
> in a way which doesn't break upgrades for previous users.
> 
> So at Folsom keystone had 15 migrations... In order to upgrade to
> Grizzly users would need to be at migration 15 (or greater). New
> installations would automatically run the 'compacted' migration
> which initializes their schema to version 15 as well so they will be
> upgraded in a similar fashion. New migrations added in the grizzly
> timeframe should remain in order and untouched.
> 
> Make sense?
> 
> Dan
> 
> > 
> > Thanks for the feedback, and apologies for any inconvenience!
> > 
> > 
> > -Dolph
> > 
> > 
> > On Wed, Feb 27, 2013 at 7:43 AM, Mark McLoughlin
> > <markmc at redhat.com>
> > wrote:
> > 
> > > 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.
> > >
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > 
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>