<div dir="ltr">Ihar, thanks for bringing this up!<div><br></div><div>This is very interesting and I think it worth trying. I'm +1 on that and want to participate in this work.</div><div><br></div><div>In fact a lot *not strict* migrations are removed with juno_initial, so I hope it won't be so hard for now to apply <span style="font-size:12.8000001907349px">stricter </span>rules for migration. But what is the plan for those migrations that are *not strict* now? </div><div><br></div><div>I think that we should try to use Alembic as much we could as Mike is going to support us in that and we have time to make some change in Alembic directly. </div><div><br></div><div>We should undoubtedly plan this work for M release because there will be some issues that will appear in the process.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 16, 2015 at 6:58 PM, Mike Bayer <span dir="ltr"><<a href="mailto:mbayer@redhat.com" target="_blank">mbayer@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 6/16/15 11:41 AM, Ihar Hrachyshka wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br></span><span class="">
- - instead of migrating data with alembic rules, migrate it in runtime.<br>
There should be a abstraction layer that will make sure that data is<br>
migrated into new schema fields and objects, while preserving data<br>
originally stored in 'old' schema elements.<br>
<br>
That would allow old neutron-server code to run against new schema (it<br>
will just ignore new additions); and new neutron-server code to<br>
gradually migrate data into new columns/fields/tables while serving user<br>
s.<br>
</span></blockquote>
Hi Ihar -<br>
<br>
I was in the middle of writing a spec for neutron online schema migrations, which maintains "expand / contract" workflow but also maintains Alembic migration scripts.   As I've stated many times in the past, there is no reason to abandon migration scripts, while there are many issues related to abandoning the notion of the database in a specific versioned state as well as the ability to script any migrations whatsoever.   The spec amends Nova's approach and includes upstream changes to Alembic such that both approaches can be supported using the same codebase.<span class="HOEnZb"><font color="#888888"><br>
<br>
- mike</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Regards,<div>Ann Kamyshnikova</div><div>Mirantis, Inc</div></div></div>
</div>