I may have missed this in the discussions, but does this impact on upgrade?
I am guessing you have tested Essex -> Folsom upgrade, but does this affect people upgrading from any of the Essex milestones to Folsom? I guess the deeper question is which upgrade paths do we want to maintain... Thanks, John > -----Original Message----- > From: openstack-bounces+john.garbutt=eu.citrix....@lists.launchpad.net > [mailto:openstack-bounces+john.garbutt=eu.citrix....@lists.launchpad.net] > On Behalf Of Dan Prince > Sent: 02 May 2012 21:20 > To: Vishvananda Ishaya > Cc: openstack@lists.launchpad.net > Subject: Re: [Openstack] database migration cleanup > > > > ----- Original Message ----- > > From: "Vishvananda Ishaya" <vishvana...@gmail.com> > > To: "Dan Prince" <dpri...@redhat.com> > > Cc: openstack@lists.launchpad.net > > Sent: Thursday, April 26, 2012 4:14:25 PM > > Subject: Re: [Openstack] database migration cleanup > > > > +1. Might be nice to have some kind of test to verify that the new > > migration leaves the tables in exactly the same state as the old > > migrations. > > Hey Vish, > > This is an outline of what I did to test MySQL and PostgreSQL to ensure the > compact migration script generates *exactly* the same schemas as before: > > http://wiki.openstack.org/database_migration_testing > > As things stand both MySQL and PostgreSQL are exactly the same. I have > some pending changes that I've found in the schemas that need to be fixed > in Folsom... but the goal here was to replicate Essex with migration 082 so > that is what I did. > > Sqlite has a few differences (indexes for example). How important is it that > the Sqlite schema be exactly the same? Unit tests are passing. > > Dan > > > > > > Vish > > > > On Apr 26, 2012, at 12:24 PM, Dan Prince wrote: > > > > > The OpenStack Essex release had 82 database migrations. As these > > > grow in number it seems reasonable to clean house from time to time. > > > Now seems as good a time as any. > > > > > > I came up with a first go at it here: > > > > > > https://review.openstack.org/#/c/6847/ > > > > > > The idea is that we would: > > > > > > * Do this early in the release cycle to minimize risk. > > > > > > * Compact all pre-Folsom migrations into a single migration. This > > > migration would be used for new installations. > > > > > > * New migrations during the Folsom release cycle would proceed as > > > normal. > > > > > > * Migrations added during Folsom release cycle could be compacted > > > during "E" release cycle. TBD if/when we do the next compaction. > > > > > > * Users upgrading from pre-Essex would need to upgrade to Essex > > > first. Then Folsom. > > > > > > -- > > > > > > I think this scheme would support users who follow stable releases > > > as well as users who follow trunk very closely. > > > > > > We talked about this at the conference but I thought this issue > > > might be near and dear to some of our end users so it was worth > > > discussing on the list. > > > > > > What are general thoughts on this approach? > > > > > > Dan (dprince) > > > > > > _______________________________________________ > > > Mailing list: https://launchpad.net/~openstack > > > Post to : openstack@lists.launchpad.net > > > Unsubscribe : https://launchpad.net/~openstack > > > More help : https://help.launchpad.net/ListHelp > > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp