[openstack-dev] [Nova] Live upgrades and major rpc versions
rbryant at redhat.com
Fri Dec 20 20:26:52 UTC 2013
Bumping the major rpc versions allows us to drop old backwards
compatibility code. However, we have to do this in such a way that
doesn't break live upgrades. We've expected live upgrades for CD to
work for a while, and we're also expecting to be able to support it from
Havana to Icehouse.
The approach for bumping major rpc versions in the past has been like this:
Step 1) https://review.openstack.org/#/c/53944/
Step 2) https://review.openstack.org/#/c/54493/
The approach outlined in the commit message for step 1 discusses how
this approach works with live upgrades in a CD environment. However,
making changes like this in the middle of a release cycle breaks the
live upgrade from the N-1 to N release.
(Yes, these changes broke Havana->Icehouse live upgrades, but that has
since been resolved with some other patches. This discussion is how we
avoid breaking it in the future.)
To support N-1 to N live upgrades, I propose that we use the same change
structure, but split it over a release boundary. A practical example
for the conductor service:
Step 1) https://review.openstack.org/#/c/52218/
This patch adds a new revision of the conductor rpc API, 2.0. I say we
merge a change like this just before the Icehouse release. The way it's
written is very low risk to the release since it leaves most important
existing code (1.X) untouched.
Step 2) https://review.openstack.org/#/c/52219/
Once master is open for J development, merge a patch like this one as
step 2. At this point, we would drop all support for 1.X. It's no
longer needed because in J we're only trying to support upgrades from
Icehouse, and Icehouse supported 2.0.
Using this approach I think we can support live upgrades from N-1 to N
while still being able to drop some backwards compatibility code each
Once we get the details worked out, I'd like to capture the process on
the release checklist wiki page for Nova.
More information about the OpenStack-dev