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

Author: sbauza

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:
 

nova/objects/service.py

@@ -237,15 +237,30 @@
 # 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,
 }