On Jul 18, 2013, at 4:19 AM, Sean Dague <s...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
