> +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 _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
