Open Stack

----- Original Message -----
> From: "Doug Hellmann" <doug.hellmann at dreamhost.com>
> To: "OpenStack Development Mailing List" <openstack-dev at lists.openstack.org>
> Sent: Wednesday, February 27, 2013 12:21:14 PM
> Subject: Re: [openstack-dev] [keystone] re-ordering of schema migrations
> 
> On Wed, Feb 27, 2013 at 9:59 AM, Dan Prince <dprince at redhat.com>
> wrote:
> 
> >
> >
> > ----- 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?
> >
> 
> Yeah. Let's not do that, though. Let's just add new migrations as
> necessary. That way each migration is tested, and after it is known
> to work
> it is not changed to something different that has to be re-tested.


I don't think Keystone has reached this point either. At some point though the number or migrations becomes unwieldy and compacting things may make more sense though.


> 
> Doug
> 
> 
> >
> > 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
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>