openstack team mailing list archive

[John Garbutt <John.Garbutt@xxxxxxxxxx>]

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.com@xxxxxxxxxxxxxxxxxxx
> [mailto:openstack-bounces+john.garbutt=eu.citrix.com@xxxxxxxxxxxxxxxxxxx]
> On Behalf Of Dan Prince
> Sent: 02 May 2012 21:20
> To: Vishvananda Ishaya
> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack] database migration cleanup
> 
> 
> 
> ----- Original Message -----
> > From: "Vishvananda Ishaya" <vishvananda@xxxxxxxxx>
> > To: "Dan Prince" <dprince@xxxxxxxxxx>
> > Cc: openstack@xxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxxxx
> > > Unsubscribe : https://launchpad.net/~openstack
> > > More help   : https://help.launchpad.net/ListHelp
> >
> >
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp