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):
https://review.openstack.org/#/c/54493/
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.
[1] https://review.openstack.org/#/c/12130/
[2] https://review.openstack.org/#/c/12131/
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
