Re: [openstack-dev] [Neutron][stable] How to backport database schema fixes

[Russell Bryant]

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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][stable] How to backport database schema fixes

[Salvatore Orlando]

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  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/
> 
>
> --
> 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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev