Open Stack

On 10/31/2013 11:23 AM, Jay Pipes wrote:
> On 10/31/2013 08:01 AM, Sean Dague wrote:
>> So there is a series of patches starting with -
>> https://review.openstack.org/#/c/53417/ that go back and radically
>> change existing migration files.
>>
>> This is really a no-no, unless there is a critical bug fix that
>> absolutely requires it. Changing past migrations should be considered
>> with the same level of weight as an N-2 backport, only done when there
>> is huge upside to the change.
>>
>> I've -2ed the first 2 patches in the series, though that review applies
>> to all of them (I figured a mailing list thread was probably more useful
>> than -2ing everything in the series).
>>
>> There needs to be really solid discussion about the trade offs here
>> before contemplating something as dangerous as this.
>
> +1

There is a very real reason why we have a firm stance on this. There are 
a huge number of OpenStack instances out in the field, at all sorts of 
different past versions. We really try to promise that you can always 
forward upgrade your database.

If you go back and change an old migration, you have not forked the 
past. Some people will have already taken that migration, and they have 
one view of the world, others haven't yet, they hit your updated 
version, and they now have different database. So 2 people with Havana 
would no longer be guaranteed to have the same data model set up by us.

It's easy to believe that "this change is really straight forward, it 
will be exactly the same model", but if it isn't, in any way, exactly 
the same (even in a way that we didn't realize yet that it mattered), 
you've forked the past. And that makes supporting users in these various 
forked versions of the world impossible.

Migrations are basically idempotent. If you want to clean things up, do 
them in a new migration. Don't touch an old one unless it is causing 
corruption to someone's data so that fixing it with a future migration 
is not an option.

	-Sean

-- 
Sean Dague
http://dague.net