On 9/4/2018 4:27 PM, melanie witt wrote:
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.
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.
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.
-- Thanks, Matt __________________________________________________________________________ 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
