openstack/nova
Code Issues Proposed changes

Merge "Add service version for Antelope"

Browse Source
This commit is contained in:
Zuul 2023-03-03 06:15:47 +00:00 committed by Gerrit Code Review
commit 59f7a524fd
2 changed files with 31 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
doc/source/admin/upgrades.rst
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:

21
nova/objects/service.py
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,
}