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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
