openstack/governance
Code Issues Proposed changes

Add supported upgrade-path testing in PTI

Browse Source 
We discussed the upgarde path testing in PTG[1] and agreed to
support two distro version when a release bumping to new version.

Let's document the existing and new testing recommendation for
upgrade in PTI.

Also change the 2023.1 tetsing runtime accordingly.

[1] https://etherpad.opendev.org/p/tc-2023-1-ptg#L422

Change-Id: I829ad6325f92c9162edf61046d3a46cb61e55a09
This commit is contained in:
Ghanshyam Mann 2022-10-06 13:21:46 -05:00
parent bd62804d01
commit dab279d1d4
2 changed files with 82 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

66
reference/project-testing-interface.rst
View File

@ -142,6 +142,72 @@ based on the LTS or stable release of the :ref:`pti-linux-distros` at the start
the development cycle. Distros are listed in testing runtime based on the
required minimum testing as described in :ref:`pti-linux-distros`
Upgrade testing
^^^^^^^^^^^^^^^
Along with testing the distro versions defined in testing runtime, projects
need to take care of the supported upgrade path also. For the supported upgrade
path, projects need to make sure that new release code and its supported
configuration works on the distros supported by the upgrade-supported previous
releases of OpenStack.
With `SLURP <https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html>`_
upgrade support, along with release to release (N-1 -> N) upgrade we need
to take care of skip-level upgrade also.
#. non-SLURP release N (N-1 -> N upgrade)
Every non-SLURP release need to support N-1 -> N upgrade. In this upgrade
path, N (non-SLURP release) code and supported configuration should continue
working on distro versions supported and defined by the N-1 release
testing runtime.
#. SLURP release N (N-1 -> N and N-2 -> N upgrade)
Every SLURP release need to support N-1 -> N as well as the N-2 -> N
upgrade. In this upgrade path, N (SLURP release) code and supported
configuration should continue working on distro versions supported and
defined by the N-1 as well as the N-2 release testing runtime.
For smooth upgrade, try to avoid changes in dependencies which are not present
in old release supported distro. In case any project has to do it due to its
new features dependencies then communicate it explicitly in upgrade status
tool, release notes etc. Also, make it clear if project existing functionality
can still work fine on the old distro version but the new features require
the new distro version will not be available until the distro version is
upgraded.
Extending support and testing for release with the newer disto version
``````````````````````````````````````````````````````````````````````
When any release bumps the minimum supported distro platform or python version,
the following things need to be addressed:
#. Support the old distro version also along with the new version. Basically two
distro versions will be supported in testing runtime for a release changing
the distro version. Explicitly mention about old PTI support in testing
runtime.
* For old distro version testing, we do not need to run all jobs on that
version, instead running a single tempest job in project gate on old distro
version will be sufficient.
* Make sure to keep the old distro default python version in testing runtime.
Example: :ref:`2023.1 cycle testing runtime <2023-1-testing-runtime>`
#. Do not add the new PTI (distro, python new version) to the non-SLURP testing
runtime. We may need to remove the old PTI which was additionally supported
for smooth upgrade in previous release. If we have to add the new PTI in
the non-SLURP testing runtime then we need to make sure the old distro
supported in the immediately previous SLURP release is also tested in the
next SLURP release. This will make sure that the old and the new distros are
tested between SLURP releases also.
The verification can be done via integrated testing and upgrade testing for example,
tempest, grenade or similar upgrade testing jobs running with default and supported
configuration.
The officially tested runtimes for each cycle can be found here:
.. toctree::

17
reference/runtimes/2023.1.rst
View File

@ -1,3 +1,5 @@
.. _2023-1-testing-runtime:
==========================
Tested Runtimes for 2023.1
==========================
@ -8,6 +10,15 @@ distribution <pti-linux-distros>` versions are:
* Ubuntu 22.04
* Debian 11
Additional testing for smooth upgrade
-------------------------------------
In this release, we are adding the testing of Ubuntu new version 22.04.
For smooth upgrade, we will continue the minimum testing for previously
supported Ubuntu version in this release.
* Ubuntu 20.04
Best Effort
-----------
@ -27,9 +38,13 @@ when all projects have migrated to a later version.
Based on the criteria above, all Python-based projects must target and test
against, at a minimum:
* Python 3.9 (available as default in Debian 11)
* Python 3.8 (available as default in Ubuntu 20.04)
* Python 3.10 (available as default in Ubuntu 22.04)
Other than the above Python versions, Debian 11 has Python 3.9 as default which
we are not suggesting to run unit tests. We assume that anything that works on
Python 3.8 and 3.10 will also work on 3.9.
More details on Python requirements can be found in :ref:`pti-python`.
Node.js Runtime for 2023.1