>> Yes, we should definitely trim the placement DB migrations to only >> things relevant to placement. And we can use this opportunity to get >> rid of cruft too and squash all of the placement migrations together >> to start at migration 1 for the placement repo. If anyone can think >> of a problem with doing that, please shout it out.
I agree, FWIW. > Umm, nova-manage db sync creates entries in a sqlalchemy-migrate > versions table, something like that, to track per database what the > latest migration sync version has been. > > Based on that, and the fact I thought our DB extraction policy was to > mostly tell operators to copy the nova_api database and throw it > elsewhere in a placement database, then the migrate versions table is > going to be saying you're at 061 and you can't start new migrations > from 1 at that point, unless you wipe out that versions table after > you copy the API DB. They can do this, sure. However, either we'll need migrations to delete all the nova-api-related tables, or they will need to trim them manually. If we do the former, then everyone who ever installs placement from scratch will go through the early history of nova-api only to have that removed. Or we trim those off the front, but we have to keep the collapsing migrations until we compact again, etc. The thing I'm more worried about is operators being surprised by this change (since it's happening suddenly in the middle of a release), noticing some split, and then realizing that if they just point the placement db connection at nova_api everything seems to work. That's going to go really bad when things start to diverge. > I could be wrong, but just copying the database, squashing/trimming > the migration scripts and resetting the version to 1, and assuming > things are going to be hunky dory doesn't sound like it will work to > me. Why not? I think the safest/cleanest thing to do here is renumber placement-related migrations from 1, and provide a script or procedure to dump just the placement-related tables from the nova_api database to the new one (not including the sqlalchemy-migrate versions table). --Dan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev