<div dir="ltr"><div>Hello everyone!</div><div><br></div><div>I would like to try to solve this problem. I registered blueprint on this topic <a href="https://blueprints.launchpad.net/neutron/+spec/neutron-robust-db-migrations">https://blueprints.launchpad.net/neutron/+spec/neutron-robust-db-migrations</a> and I'm going to experiment with options to solve this. I'm welcome any suggestions and ready to talk about it via IRC (akamyshnikova).</div>
<div><br></div><div>Regards</div><div>Ann</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 14, 2014 at 9:39 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</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 04/14/2014 12:46 PM, Eugene Nikanorov wrote:<br>
> Hi Salvatore,<br>
><br>
> The described problem could be even worse if vendor drivers are considered.<br>
> Doesn't #1 require that all DB tables are named differently? Otherwise<br>
> it seems that user can't be sure in DB schema even if all tables are<br>
> present.<br>
><br>
> I think the big part of the problem is that we need to support both<br>
> online and offline migrations. Without the latter things could be a<br>
> little bit simpler.<br>
><br>
> Also it seems to me that problem statement should be changed to the<br>
> following:<br>
> One need to migrate from (Config1, MigrationID1) to (Config2,<br>
> MigrationID2), and currently our code only accounts for MigrationIDs.<br>
> We may consider amending DB with configuration metadata, at least that<br>
> will allow to run migration code with full knowledge of what happened<br>
> before (if online mode is considered).<br>
> In offline mode that will require providing old and current configurations.<br>
><br>
> That was just thinking aloud, no concrete proposals yet.<br>
<br>
</div>The root issue really is Migrations *must* be global, and config<br>
invariant. That's the design point in both sqlalchemy-migrate and<br>
alembic. The fact that there is one global migrations table per<br>
database, with a single value in it, is indicative of this fact.<br>
<br>
I think that design point got lost somewhere along the way, and folks<br>
assumed migrations were just a way to change schemas. They are much more<br>
constrained than that.<br>
<br>
It does also sound like the data model is going to need some serious<br>
reconsidering given what's allowed to be changed at the plugin or vendor<br>
driver model. Contrast this with Nova, were virt drivers don't get to<br>
define persistant data that's unique to them (only generic data that<br>
they fit into the grander nova model).<br>
<br>
The one time we had a driver which needed persistent data (baremetal) it<br>
managed it's own database entirely.<br>
<span class="HOEnZb"><font color="#888888"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
Samsung Research America<br>
<a href="mailto:sean@dague.net">sean@dague.net</a> / <a href="mailto:sean.dague@samsung.com">sean.dague@samsung.com</a><br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</font></span><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>