Bug 1046754

Summary:	[RFE][nova]: Make rpc upgrade_levels automatically discoverable
Product:	Red Hat OpenStack	Reporter:	RHOS Integration <rhos-integ>
Component:	RFEs	Assignee:	RHOS Maint <rhos-maint>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	markmc, yeylon
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
URL:	https://blueprints.launchpad.net/nova/+spec/automatic-rpc-upgrade-levels-discovery
Whiteboard:	upstream_milestone_next upstream_status_unknown upstream_definition_new
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-19 17:12:18 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description RHOS Integration 2013-12-26 22:55:31 UTC

Cloned from launchpad blueprint https://blueprints.launchpad.net/nova/+spec/automatic-rpc-upgrade-levels-discovery.

Description:

Today when someone wants do a rolling upgrade of nova-compute they have to:

1) Upgrade everything except nova-compute.
2) While upgrading, set the rpc version cap config option in nova.conf (upgrade_levels.compute) to the version of nova-compute being used.
3) Roll out the new nova-computes.
4) Remove the rpc version cap under upgrade_levels.compute.

A deployer shouldn't have to deal with setting rpc version caps via config files every time they want to upgrade, this process should be taken care of by nova itself.   Nova should be able to discover what message versions a specific service supports.

With this blueprint the same upgrade should look like:

1) Upgrade everything except nova-compute. the new services automatically detect that a rpc version cap is needed to talk to the nova-computes.
3) Roll out the new nova-computes. rpc version cap is automatically dropped.

There are several possible ways to implement this including adding a rpc_version column to the services table.

Since we already have a working solution for rolling upgrades, this blueprint is not a requirement for rolling upgrades, but rather a nice to have.

This blueprint was drafted with the goal of targeting Juno.

Specification URL (additional information):

None