Open Stack

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 <dms at 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-request at 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. mnaser at vexxhost.com
W. http://vexxhost.com