This section describes the structure of the OpenStack formulas related to upgrades. This defines the upgrade API for the formulas that consist of the states described in the table below. By using these states, you can build a flexible upgrade logic for a particular use-case.
| State | Description |
|---|---|
<app>.upgrade.service_running |
Verify that all services for a particular application are enabled for autostart and running. |
<app>.upgrade.service_stopped |
Verify that all services for a particular application are disabled for autostart and dead. |
<app>.upgrade.pkg_latest |
Verify that the packages used by a particular application
are upgraded to the latest available version.
This will not upgrade the data plane packages like QEMU
and OVS since usually a minimal required version
in OpenStack services is really old. The data plane
packages should be upgraded separately by
apt-get upgrade or apt-get dist-upgrade.
Application of this state will not autostart service. |
<app>.upgrade.render_config |
Verify that the configuration is rendered to an actual version. |
<app>.upgrade.pre |
We assume this state is applied on all nodes in the
cloud before running the upgrade.
Only non-destructive actions will be applied during
this phase. Perform the built-in service check
such as keystone-manage doctor and nova-status upgrade. |
<app>.upgrade.upgrade.pre |
Mostly applicable for the data plane nodes. During this
phase, resources will be gracefully removed from the
current node if it is possible. The services of the
upgraded applications will be set to the admin disabled
state to make sure that a node will not participate in the
resources scheduling. For example on the gtw nodes, this
will set all agents to the admin disabled state and move all
routers to other agents. |
<app>.upgrade.upgrade |
Upgrade applications on a particular target node. Stop services,
render configuration, install new packages, run offline
dbsync for the ctl nodes, start services. The data plane should
not be affected, only OpenStack Python services. |
<app>.upgrade.upgrade.post |
Add services back to scheduling. |
<app>.upgrade.post |
This phase should be launched only when the cloud upgrade is completed. During this phase, some services may be restarted and minimal downtime may occur. |
<app>.upgrade.verify |
Perform the basic health checks such as the API CRUD operations, verification of the failed network agents and compute services. |
The upgrade pillar has the following structure:
<app>:
upgrade:
upgrade_enabled: true|false
old_release: <release of openstack we upgrade from>
new_release: <release of ipenstack we upgrade to>
Also, an application can use additional upgrade parameters to control the upgrade behaviour. For example, to disable the Neutron router migration, configure the pillar as follows:
neutron:
upgrade:
resource_migration:
l3:
enabled: false