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
