Open Stack

>> 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