Open Stack

On 10/31/2013 11:56 AM, Sean Dague wrote:
> 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.

LOL, I was +1'ing your thoughts, not +1'ing the proposal to have a solid 
discussion about the trade-offs :)

Sorry for the confusion!
-jay