From dab279d1d49ebdc83f68e566823d04fb95104031 Mon Sep 17 00:00:00 2001 From: Ghanshyam Mann Date: Thu, 6 Oct 2022 13:21:46 -0500 Subject: [PATCH] Add supported upgrade-path testing in PTI 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 --- reference/project-testing-interface.rst | 66 +++++++++++++++++++++++++ reference/runtimes/2023.1.rst | 17 ++++++- 2 files changed, 82 insertions(+), 1 deletion(-) diff --git a/reference/project-testing-interface.rst b/reference/project-testing-interface.rst index 31c58b435..8e5ca0b2e 100644 --- a/reference/project-testing-interface.rst +++ b/reference/project-testing-interface.rst @@ -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 `_ +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:: diff --git a/reference/runtimes/2023.1.rst b/reference/runtimes/2023.1.rst index a914605d3..fbbd9a1e4 100644 --- a/reference/runtimes/2023.1.rst +++ b/reference/runtimes/2023.1.rst @@ -1,3 +1,5 @@ +.. _2023-1-testing-runtime: + ========================== Tested Runtimes for 2023.1 ========================== @@ -8,6 +10,15 @@ distribution ` 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