Open Stack

> So how much damage has been done in the migrations so far? is it 
> recoverable at this point so that someone who has been tracking 
> forward will have a db anything like someone that went from F -> G?
>
>     -Sean
>
This is a first analysis, have not attempted to verify the steps:


If someone was tracking individual commits, they should have seen a 
problem back when we first renumbered them.  That was merged Feb 1.

If someone is at the G2 state, I think they are safe if they downgrade 
their database to version 007 and then run the Grizzly Update.   The 
renumbering was done on 008 and forward.

We don't have a downgrade script for 006 in place: should not be that 
hard to write one, but it would have to be release ex-post facto.  I 
think that downgrading to this point is not necessary, but if it is, we 
should be able to rerun the 006 script. It will attempt to create the 
policy table, which already exists.  However, the upgrade script does:

  policy_table.create(migrate_engine, checkfirst=True)

Which (I think) succeeds if the table already exists.  This table is not 
later modified.

G2 had the group tables, so group data would be lost.  That could be 
backed up and recovered manually.  They should be in the same state 
before and after any migration.

That is what could be done using the tools in the field.  I agree it is 
nasty.

 From Folsom to Grizzly we should be OK:  Folsom only goes as far as 
004.  Migrations forward from there will work.