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