Jump to: navigation, search

Difference between revisions of "QA/releases"

< QA
(Project with release mode: cycle-with-intermediary)
 
(16 intermediate revisions by 3 users not shown)
Line 10: Line 10:
  
 
* Tempest: Week R-3 (Hard StringFreeze) of cycle release schedule. Example [https://releases.openstack.org/victoria/schedule.html Victoria Release Schedule]
 
* Tempest: Week R-3 (Hard StringFreeze) of cycle release schedule. Example [https://releases.openstack.org/victoria/schedule.html Victoria Release Schedule]
 +
** The following is the subject of Feature Freeze:
 +
*** New tests
 +
**** New API tests are OK to merge after seeing a green gate
 +
**** Scenario tests need to be discussed during QA office hour and will be decided based on their complexity
 +
*** New dependencies/dependency bumps
 +
**** Not to be merged unless necessary for the release.
 +
*** Non-stable/stable interface
 +
**** Any removal of deprecated interfaces or variable or any change which has possibility of breaking the plugins users.
 +
**** If non-deprecated interface then we need to postpone to the next cycle.
 +
*** Any framework change will be checked dynamically and decided whether to postpone to the next release or not.
 +
 
* Devstack: Week R-3 (Hard StringFreeze) of cycle release schedule.
 
* Devstack: Week R-3 (Hard StringFreeze) of cycle release schedule.
 +
** The following is the subject of Feature Freeze:
 +
*** Changing the default behavior/configuration.
 +
*** New backup/driver support if it's not isolated.
 +
 
* Grenade: Week R-3 (Hard StringFreeze) of cycle release schedule.
 
* Grenade: Week R-3 (Hard StringFreeze) of cycle release schedule.
 +
** The following is the subject of Feature Freeze:
 +
*** Changing the default behavior/configuration.
 +
 
* Patrole: Week R-3 (Hard StringFreeze) of cycle release schedule.
 
* Patrole: Week R-3 (Hard StringFreeze) of cycle release schedule.
 
+
** The following is the subject of Feature Freeze:
 +
*** Same as for Tempest.
  
 
== Project with release mode: cycle-with-intermediary ==
 
== Project with release mode: cycle-with-intermediary ==
Line 19: Line 38:
 
=== Tempest ===
 
=== Tempest ===
  
 +
* Step0: Read and follow the "How to pin upper-constraints in tox.ini" steps.
 +
** https://docs.openstack.org/tempest/latest/requirement_upper_constraint_for_tempest.html
 
* Step1: Add Release note to mark the release
 
* Step1: Add Release note to mark the release
 
** Example:
 
** Example:
Line 34: Line 55:
 
** Example: https://review.opendev.org/#/c/687619/  
 
** Example: https://review.opendev.org/#/c/687619/  
 
* Step5: Remove the End of Support branch job from tempest gate if release is for end of support for any stable branch
 
* Step5: Remove the End of Support branch job from tempest gate if release is for end of support for any stable branch
** Example: https://review.opendev.org/#/c/703646/
+
** Example: https://review.opendev.org/#/c/766770/
 
 
=== Patrole ===
 
 
 
* Step1: Add Release note to mark the release
 
** Example: https://review.opendev.org/#/c/685429/
 
* Step2: Push release tag to openstack/release repo
 
** Example: https://review.opendev.org/#/c/685430/
 
* Step3: Add release notes page after release patch is merged
 
** Example: https://review.opendev.org/#/c/687124/
 
* Step4: Add releasenotes page link in openstck/release
 
** Example: https://review.opendev.org/#/c/687582/
 
* Step5: Remove the End of Support branch job from tempest gate if release is for end of support for any stable branch:
 
  
 
== Project with release mode: independent ==
 
== Project with release mode: independent ==
Line 61: Line 70:
 
** Example: https://review.opendev.org/#/c/710561/
 
** Example: https://review.opendev.org/#/c/710561/
 
* eslint-config-openstack
 
* eslint-config-openstack
 +
** Example: https://review.opendev.org/#/c/785024/
  
 
== Project with no release==
 
== Project with no release==
Line 67: Line 77:
  
 
* coverage2sql
 
* coverage2sql
* devstack-plugin-ceph
 
 
* devstack-plugin-cookiecutter
 
* devstack-plugin-cookiecutter
 
* devstack-plugin-open-cas
 
* devstack-plugin-open-cas
Line 78: Line 87:
 
* tempest-stress
 
* tempest-stress
 
* tempest-plugin-cookiecutter
 
* tempest-plugin-cookiecutter
 
  
 
= Projects with only Branches =
 
= Projects with only Branches =
Line 99: Line 107:
 
**** https://review.opendev.org/#/c/687115/
 
**** https://review.opendev.org/#/c/687115/
 
**** https://review.opendev.org/#/c/687176/
 
**** https://review.opendev.org/#/c/687176/
** Step7: After Devstack has been branched.  Add a new stable branch job in the Tempest pipeline.
+
** Step7: Update INSTALL_TEMPEST to False on stable/foo
*** Example: https://review.opendev.org/#/c/686781
+
*** Example: https://review.opendev.org/c/openstack/devstack/+/774877
** Step8: After Devstack has been branched.  Configure devstack-gate to run the new stable branch jobs.
+
** Step8: After Devstack has been branched.  Add a new stable branch job in the Tempest pipeline.
*** Example: https://review.opendev.org/#/c/686776/
+
*** https://review.opendev.org/c/openstack/tempest/+/810998
 
** Step9: After Devstack has been branched.  Add the new stable branch to the list of branches in the periodic-stable job templates in openstack-zuul-jobs.
 
** Step9: After Devstack has been branched.  Add the new stable branch to the list of branches in the periodic-stable job templates in openstack-zuul-jobs.
*** Example: https://review.opendev.org/#/c/687122/  
+
*** Example: https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/810999
  
 
* Grenade
 
* Grenade
** Step1: Wait for stable/branch to exist on Devstack
+
** Step1: Wait for stable/foo to exist on Devstack
 
** Step2: Propose  to openstack/releases to create a stable/foo branch  
 
** Step2: Propose  to openstack/releases to create a stable/foo branch  
 
*** Example: https://review.opendev.org/#/c/686771/
 
*** Example: https://review.opendev.org/#/c/686771/
** Step3: Update .gitreview for stable/x – from OpenStack Release Bot  
+
** Step3: Update .gitreview for stable/foo – from OpenStack Release Bot  
 
*** Example: https://review.opendev.org/#/c/686991/  
 
*** Example: https://review.opendev.org/#/c/686991/  
** Step5: Update devstack-gate logic to use the new branches
+
** Step4: Update the master grenade setting for stable/foo to master upgrade
*** Example: new- https://review.openstack.org/#/c/591594/
+
*** Example: https://review.opendev.org/c/openstack/grenade/+/785006
 +
** Step5: Update grenade setting in stable/foo
 +
*** https://review.opendev.org/c/openstack/grenade/+/785007
  
* devstack-plugin-container: hanled by devstack-plugin-container team.
+
* devstack-plugin-container:
 +
** Once devstack is branched, push the final release with the current hash to cut the branch, similar to devstack.
 +
*** Example: https://review.opendev.org/c/openstack/releases/+/785180
 +
 
 +
* devstack-plugin-ceph
 +
** Once devstack is branched, push the final release with the current hash to cut the branch, similar to devstack.
 +
*** Example: https://review.opendev.org/c/openstack/releases/+/786069
  
Once all done then you deserve to go for beer \o/
+
Once all is done then you deserve to go for beer \o/

Latest revision as of 20:04, 22 September 2023

OpenStack QA releases its tooling as per each tool release model and also needs to take care of the new branch set on devstack and grenade. This page explain the process and tasks QA team needs to do on every OpenStack release.

Project Releases

Feature Freeze

QA projects follow different release models (explained in the next section) so feature freeze is not applicable to all of them. We do feature freeze for below projects only:

  • Tempest: Week R-3 (Hard StringFreeze) of cycle release schedule. Example Victoria Release Schedule
    • The following is the subject of Feature Freeze:
      • New tests
        • New API tests are OK to merge after seeing a green gate
        • Scenario tests need to be discussed during QA office hour and will be decided based on their complexity
      • New dependencies/dependency bumps
        • Not to be merged unless necessary for the release.
      • Non-stable/stable interface
        • Any removal of deprecated interfaces or variable or any change which has possibility of breaking the plugins users.
        • If non-deprecated interface then we need to postpone to the next cycle.
      • Any framework change will be checked dynamically and decided whether to postpone to the next release or not.
  • Devstack: Week R-3 (Hard StringFreeze) of cycle release schedule.
    • The following is the subject of Feature Freeze:
      • Changing the default behavior/configuration.
      • New backup/driver support if it's not isolated.
  • Grenade: Week R-3 (Hard StringFreeze) of cycle release schedule.
    • The following is the subject of Feature Freeze:
      • Changing the default behavior/configuration.
  • Patrole: Week R-3 (Hard StringFreeze) of cycle release schedule.
    • The following is the subject of Feature Freeze:
      • Same as for Tempest.

Project with release mode: cycle-with-intermediary

Tempest

Project with release mode: independent

Below projects are with independent release and not associated with OpenStack cycle release.

Project with no release

Below projects are with no release and maintained as master version only.

  • coverage2sql
  • devstack-plugin-cookiecutter
  • devstack-plugin-open-cas
  • devstack-plugin-nfs
  • devstack-vagrant
  • karma-subunit-reporter
  • openstack-health
  • os-performance-tools
  • stackviz
  • tempest-stress
  • tempest-plugin-cookiecutter

Projects with only Branches

For the most part, Devstack and Grenade only have branches, which need to be cut when other projects get stable/* branches during a release.

Once all is done then you deserve to go for beer \o/