Add service version for Antelope

Also did a bit of cleanup in the text message to tell *when* we need to bump
the min service version.
Given 2023.1 is our first SLURP release, we need to clarify the level of
support we now have for rolling upgrades.

Next cycle, we should update the min version to be Zed.

Change-Id: I2dd906f34118da02783bb7755e0d6c2a2b88eb5d
This commit is contained in:
Sylvain Bauza 2023-02-23 16:31:00 +01:00
parent d443f8e4c4
commit 349100eecc
2 changed files with 31 additions and 10 deletions

View File

@ -41,21 +41,27 @@ Rolling upgrade process
To reduce downtime, the compute services can be upgraded in a rolling fashion.
It means upgrading a few services at a time. This results in a condition where
both old (N) and new (N+1) nova-compute services co-exist for a certain time
period. Note that, there is no upgrade of the hypervisor here, this is just
period (or even N with N+2 upgraded nova-compute services, see below).
Note that, there is no upgrade of the hypervisor here, this is just
upgrading the nova services. If reduced downtime is not a concern (or lower
complexity is desired), all services may be taken down and restarted at the
same time.
.. important::
Nova does not currently support the coexistence of N and N+2 or greater
:program:`nova-compute` or :program:`nova-conductor` services in the same
deployment. The `nova-conductor`` service will fail to start when a
``nova-compute`` service that is older than the previous release (N-2 or
greater) is detected. Similarly, in a :doc:`deployment with multiple cells
As of OpenStack 2023.1 (Antelope), Nova supports the coexistence of N and
N-2 (Yoga) :program:`nova-compute` or :program:`nova-conductor` services in
the same deployment. The `nova-conductor`` service will fail to start when
a ``nova-compute`` service that is older than the support envelope is
detected. This varies by release and the support envelope will be explained
in the release notes. Similarly, in a :doc:`deployment with multiple cells
</admin/cells>`, neither the super conductor service nor any per-cell
conductor service will start if any other conductor service in the
deployment is older than the previous release.
deployment is older than the N-2 release.
Releases older than 2023.1 will only support rolling upgrades for a single
release difference between :program:`nova-compute` and
:program:`nova-conductor` services.
#. Before maintenance window:

View File

@ -237,15 +237,30 @@ SERVICE_VERSION_HISTORY = (
# local node identity for single-node systems.
NODE_IDENTITY_VERSION = 65
# This is used to raise an error at service startup if older than N-1 computes
# are detected. Update this at the beginning of every release cycle to point to
# the smallest service version that was added in N-1.
# This is used to raise an error at service startup if older than supported
# computes are detected.
# NOTE(sbauza) : Please modify it this way :
# * At the beginning of a non-SLURP release (eg. 2023.2 Bobcat) (or just after
# the previous SLURP release RC1, like 2023.1 Antelope), please bump
# OLDEST_SUPPORTED_SERVICE_VERSION to the previous SLURP release (in that
# example, Antelope)
# * At the beginning of a SLURP release (eg. 2024.1 C) (or just after the
# previous non-SLURP release RC1, like 2023.2 Bobcat), please keep the
# OLDEST_SUPPORTED_SERVICE_VERSION value using the previous SLURP release
# (in that example, Antelope)
# * At the end of any release (SLURP or non-SLURP), please modify
# SERVICE_VERSION_ALIASES to add a key/value with key being the release name
# and value be the latest service version that the release supports (for
# example, before Bobcat RC1, please add 'Bobcat': XX where X is the latest
# servion version that was added)
OLDEST_SUPPORTED_SERVICE_VERSION = 'Yoga'
SERVICE_VERSION_ALIASES = {
'Victoria': 52,
'Wallaby': 54,
'Xena': 57,
'Yoga': 61,
'Zed': 64,
'Antelope': 66,
}