Open Stack

On Jul 18, 2013, at 4:19 AM, Sean Dague <sean at dague.net> wrote:

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

As a side note, there is an exception to the rule. If one of the migrations has a bug that prevents it from working in some situations, then we fix this inline. Sometimes this means we have to fix a migration inline AND add a new migration to make the same fix. This has happened in the past for migrations that would break in postgres or if certain data was in the database.

Vish

> 
> 	-Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev