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.tang@canonical.com> wrote:
Hi, all
It seems that currently it's hard to backport any database schema fix to Neutron [1] 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.
[1] 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 OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev