<div dir="ltr"><div>Hi, </div><div><br></div>Here is a link to WIP healing script <a href="https://review.openstack.org/96438">https://review.openstack.org/96438</a>. The idea on which it is based on is shown in this spec <a href="https://review.openstack.org/95738">https://review.openstack.org/95738</a>.<div>
<br>Regards,<br>Ann</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 9, 2014 at 7:07 PM, Johannes Erdfelt <span dir="ltr"><<a href="mailto:johannes@erdfelt.com" target="_blank">johannes@erdfelt.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Mon, Jun 09, 2014, Jakub Libosvar <<a href="mailto:libosvar@redhat.com">libosvar@redhat.com</a>> wrote:<br>

> I'd like to get some opinions on following idea:<br>
><br>
> Because currently we have (thanks to Ann) WIP of healing script capable<br>
> of changing database scheme by comparing tables in the database to<br>
> models in current codebase, I started to think whether it could be used<br>
> generally to db upgrades instead of "generating" migration scripts.<br>
<br>
</div>Do you have a link to these healing scripts?<br>
<div class=""><br>
> If I understand correctly the purpose of migration scripts used to be to:<br>
> 1) separate changes according plugins<br>
> 2) upgrade database scheme<br>
> 3) migrate data according the changed scheme<br>
><br>
> Since we dropped on conditional migrations, we can cross out no.1).<br>
> The healing script is capable of doing no.2) without any manual effort<br>
> and without adding migration script.<br>
><br>
> That means if we will decide to go along with using script for updating<br>
> database scheme, migration scripts will be needed only for data<br>
> migration (no.3)) which are from my experience rare.<br>
><br>
> Also other benefit would be that we won't need to store all database<br>
> models from Icehouse release which we probably will need in case we want<br>
> to "heal" database in order to achieve idempotent Icehouse database<br>
> scheme with Juno codebase.<br>
><br>
> Please share your ideas and reveal potential glitches in the proposal.<br>
<br>
</div>I'm actually working on a project to implement declarative schema<br>
migrations for Nova using the existing model we currently maintain.<br>
<br>
The main goals for our project are to reduce the amount of work<br>
maintaining the database schema but also to reduce the amount of<br>
downtime during software upgrades by doing schema changes online (where<br>
possible).<br>
<br>
I'd like to see what other haves done and are working on the future so<br>
we don't unnecessarily duplicate work :)<br>
<span class="HOEnZb"><font color="#888888"><br>
JE<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<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>
</div></div></blockquote></div><br></div>