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.


(*) 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 [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
OpenStack-dev mailing list

Reply via email to