The OpenStack formulas structure

The OpenStack formulas structure

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.

The OpenStack formulas structure

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