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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
