Open Stack

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