[openstack-dev] [nova] Maintaining backwards compatibility for RPC calls
rbryant at redhat.com
Mon Dec 2 15:50:58 UTC 2013
tl;dr - live upgrades are hard. oops.
On 11/27/2013 07:38 AM, Day, Phil wrote:
> I’m a bit confused about the expectations of a manager class to be able
> to receive and process messages from a previous RPC version. I thought
> the objective was to always make changes such that the manage can
> process any previous version of the call that could come from the last
> release, For example Icehouse code should be able to receive any
> version that could be generated by a version of Havana. Generally of
> course that means new parameters have to have a default value.
> I’m kind of struggling then to see why we’ve now removed, for example,
> the default values for example from terminate_instance() as part of
> moving to RPC version to 3.0:
> def terminate_instance(self, context, instance, bdms=None,
> def terminate_instance(self, context, instance, bdms, reservations):
> Doesn’t this mean that you can’t deploy Icehouse (3.0) code into a
> Havana system but leave the RPC version pinned at Havana until all of
> the code has been updated ?
Thanks for bringing this up. We realized a problem with the way I had
done these patches after some of them had merged.
First, some history. The first time we did some major rpc version
bumps, they were done exactly like I did them here. 
This approach allows live upgrades for CD based deployments. It does
*not* allow live upgrades from N-1 to N releases. We didn't bother
because we knew there were other reasons that N-1 to N live upgrades
would not work at that point.
When I did this patch series, I took the same approach. I didn't
account for the fact that we were going to try to pull off allowing live
upgrades from Havana to Icehouse. The patches only supported live
upgrades in a CD environment.
I need to go back and add a shim layer that can handle receiving the
latest version of messages sent by Havana to all APIs.
More information about the OpenStack-dev