Open Stack

> 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 ?

DB schema backports was a topic at StableBranch session last design
summit [*] and policy did not change: not allowed in general but
exceptions could always be discussed on stable-maint list.

> 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.

AFAIK you can't have placeholders in alembic, there was an action item
from design session for Mark to summarize his best practices for db
backports.
Mark, do you have that published somewhere?

>  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.

Again, policy stays but we can use this thread as an exception request for [1]
My thoughts: adding index on (agent_type, host) is safe for backports
as it doesn't affect code but we need to do it properly
e.g. it must not break Icehouse->Juno upgrades and have clear
instructions how to apply in stable release notes e.g. [2] for similar
case in Keystone Havana.
Also it would be good to describe the impact and "why" part in the
commit message and/or bug 1350326 description, IIUC that would be
"prevent race condition in L2 plugin" ?

Cheers,
Alan

> [1] https://review.openstack.org/#/c/110642/

[*] https://etherpad.openstack.org/p/StableIcehouse
[2] https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.2#Keystone