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,
> reservations=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. [1][2]

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.


Russell Bryant

OpenStack-dev mailing list

Reply via email to