<div dir="ltr">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.<div>
<br></div><div>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.</div>
<div>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.<br>
</div><div><br></div><div>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.</div><div><br></div><div>Salvatore</div><div><br></div>
<div>(*) we are getting rid of this conditional migration logic for juno anyway</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 29 August 2014 11:38, Yaguang Tang <span dir="ltr"><<a href="mailto:yaguang.tang@canonical.com" target="_blank">yaguang.tang@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi, all <div><br></div><div>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</div>
<div>and a workaround is to put some placeholder files before each release. </div>
<div>So first do we allow db schema fixes to be backport to stable for Neutron ? </div><div>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.</div>

<div><br></div><div> From the stable maintainer side, we have a policy for stable backport  <a href="https://wiki.openstack.org/wiki/StableBranch" target="_blank">https://wiki.openstack.org/wiki/StableBranch</a>  <br></div>
<ul style="padding:0px;margin:0.3em 0px 0px 1.6em;color:rgb(51,51,51);font-family:'Arial Unicode MS',Arial,sans-serif;font-size:14px;line-height:20px">
<li>DB schema changes is forbidden </li></ul><div><font color="#333333" face="Arial Unicode MS, Arial, sans-serif"><span style="line-height:20px">If we allow db schema backports for more than one project, I think we need to update the wiki.</span></font></div>

<div><br clear="all"><div>[1]<a href="https://review.openstack.org/#/c/110642/" target="_blank"> https://review.openstack.org/#/c/110642/</a></div><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br><div dir="ltr">
<div style="color:rgb(0,0,0);font-family:arial;font-size:small">
Tang Yaguang</div><div style="color:rgb(0,0,0);font-family:arial;font-size:small"><br></div><div style="color:rgb(0,0,0);font-family:arial;font-size:small">Canonical Ltd. | <a href="http://www.ubuntu.com/" target="_blank">www.ubuntu.com</a> | <a href="http://www.canonical.com/" target="_blank">www.canonical.com</a></div>

<div style="color:rgb(0,0,0);font-family:arial;font-size:small">gpg key: 0x187F664F<br></div><div style="color:rgb(0,0,0);font-family:arial;font-size:small"> </div></div>
</font></span></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>