Difference between revisions of "Zero downtime upgrade"
Line 8: | Line 8: | ||
Assume that Heat is deployed in the Hight-Availability mode and there are two nodes for heat-api, heat-engine and other heat components. During the upgrade, following are the possible upgrade artifacts other than python modules: | Assume that Heat is deployed in the Hight-Availability mode and there are two nodes for heat-api, heat-engine and other heat components. During the upgrade, following are the possible upgrade artifacts other than python modules: | ||
− | + | # API REQUEST RESPONSE version change | |
− | + | # Message version change | |
− | + | # Db version change. | |
More details on how to handle the Db zero down time upgrade is elaborated in this document. | More details on how to handle the Db zero down time upgrade is elaborated in this document. | ||
Line 25: | Line 25: | ||
Once these assumptions are in place, we should be able to start the migration as follows | Once these assumptions are in place, we should be able to start the migration as follows | ||
+ | |||
+ | Assume the scenario where heat is deployed with heat-engine-A and heat-engine-B and ice-house version of heat is used. | ||
+ | When these engines are upgraded to juno, followings would be the steps to be followed: | ||
+ | |||
TBD | TBD |
Revision as of 12:20, 20 October 2014
DRAFT COPY
On the enterprise public cloud, while upgrading openstack to a given latest version, the downtime should be zero (0). This wiki page provides all related information to this requirement.
- Etherpad Entry: https://etherpad.openstack.org/p/Zero_downtime_upgrade
Introduction
Assume that Heat is deployed in the Hight-Availability mode and there are two nodes for heat-api, heat-engine and other heat components. During the upgrade, following are the possible upgrade artifacts other than python modules:
- API REQUEST RESPONSE version change
- Message version change
- Db version change.
More details on how to handle the Db zero down time upgrade is elaborated in this document.
Zero down time Db upgrade
Heat is provided with db migration tool and each Heat major release is provided with given db version. Followings are the db version for the past Heat releases:
TBD
And to support zero down time upgrade, following assumptions need to be in place:
- Downward compatibility should be provided with last 2-3 versions from the current version(inclusive)
- DB migration tool take cares of upgrading/downgrading of db data with out loss.
Once these assumptions are in place, we should be able to start the migration as follows
Assume the scenario where heat is deployed with heat-engine-A and heat-engine-B and ice-house version of heat is used. When these engines are upgraded to juno, followings would be the steps to be followed:
TBD