Open Stack

On 07/18/2013 05:54 AM, Nikola Đipanov wrote:
>
> Heya,
>
> Rule is because (I believe at least) - in the spirit of continuous
> integration - people should be able to deploy continuously anything on
> master.
>
> Due to the nature of schema versioning as done by sqlalchemy-migrate -
> changing a migration would leave people doing continuous deployments,
> with broken code (or db state - depends how you look at it) as they will
> not be able to re-run the migration.
>
> This has to stay like that as long as we are using sqla-migrate I believe.u

Yes, this is the crux of it. Many OpenStack deployers deploy from git, 
not from a release, which means we should be able to go from any git 
commit in the recent past to current git, and things be right.

But more importantly, a user that upgrades weekly during Havana.

A -> B -> C -> D -> E -> F .... -> Z

needs to have the same schema as someone that decided to only upgrade 
from Grizzly to Havana at the end of the release.

A => Z (hitting all the migrations along the way, but doing this all at 
once).

So if you go back and change migration C to C' you end up with the 
possibility that getting to Z the two ways are different, because some 
of your users already applied C, and some did not.

For support reasons if we end up with users at Havana with different 
schemas.... well that's not very good (bridging on terrible).

While it's possible to get this right when you change old migrations, 
it's much much easier to get this wrong. So as a safety measure we treat 
migrations as write only, once they've landed the only way to fix them 
is to apply a new migration later. The only exception is made when the 
migration would cause data corruption that's not recoverable (like 
overly truncating a column so we would loose data).

Anyone working on migrations, or reviewing migrations, needs to be extra 
careful because of these issues.

	-Sean

-- 
Sean Dague
http://dague.net