openstack team mailing list archive

[Vishvananda Ishaya <vishvananda@xxxxxxxxx>]

+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.

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