<br><br><div class="gmail_quote">On Wed, Feb 27, 2013 at 9:59 AM, Dan Prince <span dir="ltr"><<a href="mailto:dprince@redhat.com" target="_blank">dprince@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
----- Original Message -----<br>
> From: "Dolph Mathews" <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>><br>
> To: "Mark McLoughlin" <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>>, "OpenStack Development Mailing List" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Sent: Wednesday, February 27, 2013 9:09:00 AM<br>
> Subject: Re: [openstack-dev] [keystone] re-ordering of schema migrations<br>
><br>
> This was discussed in #openstack-dev, as I recall.<br>
><br>
> The goal in these migrations was to support folsom <--> grizzly, not<br>
> necessarily supporting intermediate milestones. I'm not aware of<br>
> anyone<br>
> doing continuous deployments of keystone, if but if migrating commit<br>
> to<br>
> commit is the community's expectation, I'm more happy to ensure that<br>
> happens moving forward -- I just wasn't aware that was a concern<br>
> here.<br>
<br>
</div>We should always support upgrading between the milestones.<br>
<br>
Also, Existing migrations should never be re-ordered.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Make sense?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Dan<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Thanks for the feedback, and apologies for any inconvenience!<br>
><br>
><br>
> -Dolph<br>
><br>
><br>
> On Wed, Feb 27, 2013 at 7:43 AM, Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>><br>
> wrote:<br>
><br>
> > On Wed, 2013-02-27 at 08:09 -0500, Eoghan Glynn wrote:<br>
> > > Folks,<br>
> > ><br>
> > > When looking into an error encountered on a keystone db sync,<br>
> > > I noticed some apparent strangeness in the way keystone schema<br>
> > > migrations have been managed.<br>
> > ><br>
> > > Specifically the *rewriting* of schema migration history, see:<br>
> > ><br>
> > > <a href="https://github.com/openstack/keystone/commit/5bc46d86" target="_blank">https://github.com/openstack/keystone/commit/5bc46d86</a><br>
> > ><br>
> > > In my (albeit imperfect) understanding of sqlalchemy-migrate,<br>
> > > this<br>
> > > reordering seems to defeat the whole purpose of step-wise<br>
> > > reversible<br>
> > > migration.<br>
> > ><br>
> > > Would it even be possible to migrate a grizzly-2 deployment to<br>
> > > grizzly-3 with that re-ordering in place?<br>
> > ><br>
> > > Maybe I've missed something here, but I'd appreciate some clarity<br>
> > > on what is considered community best practice in terms of changes<br>
> > > to the migration sequence.<br>
> > ><br>
> > > Previously I would have assumed something like ...<br>
> > ><br>
> > > Invariants we maintain:<br>
> > ><br>
> > > - DB schemas must always be migrate-able across milestone<br>
> > > releases<br>
> ><br>
> > (snip good stuff)<br>
> ><br>
> > It's more than just across milestone releases, we should support<br>
> > upgrading from commit to commit. In Nova, at least, we're trying<br>
> > hard to<br>
> > avoid messing up those who are deploying continuously. I'd expect<br>
> > any<br>
> > nova-core member to reject this patch immediately.<br>
> ><br>
> > What I really don't understand is how this concern wasn't raised in<br>
> > the<br>
> > review at all:<br>
> ><br>
> > <a href="https://review.openstack.org/19780" target="_blank">https://review.openstack.org/19780</a><br>
> ><br>
> > Cheers,<br>
> > Mark.<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br>