Difference between revisions of "Zero downtime upgrade"
Kanagarajm (talk | contribs) |
|||
| Line 4: | Line 4: | ||
* Etherpad Entry: https://etherpad.openstack.org/p/Zero_downtime_upgrade | * 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: | ||
| + | |||
| + | 1. API REQUEST RESPONSE version change | ||
| + | 2. Message version change | ||
| + | 3. 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 | ||
| + | TBD | ||
Revision as of 18:02, 16 September 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:
1. API REQUEST RESPONSE version change 2. Message version change 3. 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 TBD
