The depth of the upgrade can differ depending on a use case. The following table describes the possible upgrade levels.
| Level | Description |
|---|---|
| Application upgrade | Only application packages are upgraded. Includes upgrade of application dependencies to the desired level. |
| System packages upgrade | Known as apt-get upgrade. Used to install the newest versions of
all currently installed packages on the system from the sources
enumerated in /etc/apt/sources.list. The packages are retrieved and
upgraded. Under no circumstances, the packages are removed. The
packages that are not yet installed but required are retrieved and
installed. The new versions of the currently installed packages that
cannot be upgraded without changing the installation status of another
package or packages are left at their current version. An update
must be performed first, so that apt-get can know that the new
versions of the packages are available. |
| Kernel upgrade | Known as apt-get dist-upgrade. In addition to performing the
function of upgrade, handles the changing dependencies with new
versions of packages. The apt-get tool has a smart conflict
resolution system and attempts to upgrade the most important packages
at the expense of less important ones if necessary. The dist-upgrade
command can remove some packages. The /etc/apt/sources.list
file contains the list of locations from which the desired package
files should be retreived. Reboot might be needed after this type of
upgrade. |
| Release upgrade | Known as a do-release-upgrade upgrade of a Linux distribution to a
newer major release. |
Note
To minimize the control plane downtime, we recommend performing the application level upgrade first. When the OpenStack component is fully upgraded, proceed with the system upgrade. For details, see The OpenStack formulas structure.