On 08/29/2014 06:54 AM, Salvatore Orlando wrote: > If you are running version from a stable branch, changes in DB > migrations should generally be forbidden as the policy states since > those migrations are not likely to be executed again. Downgrading and > then upgrading again is extremely risky and I don't think anybody would > ever do that. > > However, if one is running stable branch X-2 where X is the current > development branch, back porting migration fixes could make sense for > upgrading to version X-1 if the migration being fixed is in the path > between X-2 and X-1. > Therefore I would forbid every fix to migration earlier than X-2 release > (there should not be any in theory but neutron has migrations back to > folsom). For the path between X-2 and X-1 fixes might be ok.
I think it's safe to backport to X-1. The key bit is that the migration in master and the backported version must be reentrant. They need to inspect the schema and only perform the change if it hasn't already been applied. This is a good best practice to adopt for *all* migrations to make the backport option easier. > However, > rather than amending existing migration is always better to add new > migrations - even if it's a matter of enabling a given change for a > particular plugin (*). Agreed, in general. It depends on the bug. If there's an error in the migration that will prevent the original code from running properly, breaking the migration, that obviously needs to be fixed. > As nova does, the best place for doing that is > always immediately before release. Doing what, adding placeholders? Note that we actually add placeholders at the very *beginning* of a release cycle. The placeholders have to be put in place as the first set of migrations in a release. That way: 1) X-1 has those migration slots unused. 2) X has those slots reserved. If we did it just *before* release, you can't actually backport into those positions. They've already run as no-op. > With alembic, we do not need to add placeholders, but just adjust > pointers just like you would when inserting an element in a dynamic list. Good point. > (*) we are getting rid of this conditional migration logic for juno anyway Yay! -- Russell Bryant _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev