Open Stack

> +1 to everything Daniel said. Nova really expects release-to-release
> upgrades. We do online data migrations between releases. Maybe one
> reason you're getting this to work is we have a nova-manage command to
> force the migration of data between releases rather than doing the
> online data migration as resources are accessed. But there are some DB
> migrations where we do a full stop until you've migrated the data.

Yeah, this ^

We try to put blocker migrations into the stream at critical
synchronization points to make sure that anything that *has* to be
online migrated will have been complete before we roll forward (usually
because we're about to drop something or introduce a constraint).
However, I'm sure there are some subtleties we don't catch with that.

To echo and expand on what Matt said, if you're going to do an
accelerated upgrade, I would _at least_ recommend deploying the
intermediate code an running all the online migrations to completion
(after applying the intermediate schema updates) before rolling to the
next. This means running this after "db sync" for releases after it was
added:

https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L823

Just deploying the target code and running online migrations isn't
really enough, because we often remove the migration code once we know
it (should have been) run to completion. Since we can't know everyone's
upgrade cadence, and since our official support is "N-1 to N", that's
the price you pay for skipping a release.

--Dan