Merge "Add service version for Antelope"

2 files changed, 31 insertions, 10 deletions

diff --git a/doc/source/admin/upgrades.rst b/doc/source/admin/upgrades.rst
index 00a714970b..61fd0cf258 100644
--- a/doc/source/admin/upgrades.rst
+++ b/doc/source/admin/upgrades.rst
@@ -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:
 
diff --git a/nova/objects/service.py b/nova/objects/service.py
index 0ed443ef17..b17b5c2050 100644
--- a/nova/objects/service.py
+++ b/nova/objects/service.py
@@ -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,
 }