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. 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 (*). As nova does, the best place for doing that is always immediately before release. 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. Salvatore (*) we are getting rid of this conditional migration logic for juno anyway On 29 August 2014 11:38, Yaguang Tang <yaguang.t...@canonical.com> wrote: > Hi, all > > It seems that currently it's hard to backport any database schema fix to > Neutron  which uses alembic to manage db schema version. Nova has the > same issue before > and a workaround is to put some placeholder files before each release. > So first do we allow db schema fixes to be backport to stable for Neutron > ? > If we do, then how about put some placeholder files similar to Nova at the > end of each release cycle? or we have some better solution for alembic. > > From the stable maintainer side, we have a policy for stable backport > https://wiki.openstack.org/wiki/StableBranch > > - DB schema changes is forbidden > > If we allow db schema backports for more than one project, I think we need > to update the wiki. > >  https://review.openstack.org/#/c/110642/ > <https://review.openstack.org/#/c/110642/> > > -- > Tang Yaguang > > Canonical Ltd. | www.ubuntu.com | www.canonical.com > gpg key: 0x187F664F > > > _______________________________________________ > OpenStack-dev mailing list > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev