Could placement not do what happened for a while when the nova_api database was created?
I say this because I know that moving the database is a huge task for us, considering how big it can be in certain cases for us, and it means control plane outage too On Wed, Sep 5, 2018 at 9:39 AM Dan Smith <d...@danplanet.com> 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. > > 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 -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mna...@vexxhost.com W. http://vexxhost.com __________________________________________________________________________ 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
