Jump to: navigation, search

Difference between revisions of "QA/releases"

< QA
(→‎Things to remember when creating a stable branch)
(→‎Project with release mode: cycle-with-intermediary)
 
(27 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 +
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 =
 
= Project Releases =
  
−
== tempest ==
+
== Feature Freeze ==
−
 
 
−
With the start of branchless tempest there are no long any tempest releases, but instead incremental tags for each OpenStack release milestones. The tag should be incremented to coincide with either a new OpenStack release, or the EOL of a supported stable branch. For example, the tempest-2 tag was added at the Juno release and was used to mark adding support for the Kilo release. The next tag tempest-3 will be used to either signify the start of L development or the EOL of icehouse, whichever occurs first.
 
−
 
 
−
The procedure for pushing a new tempest tag is:
 
−
 
 
−
* Identify the commit you would like to tag as the next tag and write down the sha1. This can just be the current HEAD commit but make sure you use use the sha1 for the commit from the log and not some other shorthand as that will likely change
 
−
* Push the version bump in setup.cfg. For example, see: http://git.openstack.org/cgit/openstack/tempest/commit/?id=66d8831d173cd4713bff8875bd516ad132db9070 '''this step must occur before you push the tag''' or you risk breaking pbr's semver check
 
−
* Once the version bump is in master you can tag the release and push it to gerrit with:
 
  
−
        git tag -s 3  $(sha1_to_tag) && git push gerrit 3
+
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:
  
−
this will add the signed tag to the git repo and generate a tarball and store it here: http://tarballs.openstack.org/tempest/
+
* 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.
  
−
== tempest-lib ==
+
* 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.
  
−
The mechanics for pushing a new tempest-lib release are basically the same (pushing a tag to gerrit) however the operations that get performed during this process are different. Also tempest-lib conforms to more traditional semver scheme and adheres to the mantra "release early, release often"
+
* Grenade: Week R-3 (Hard StringFreeze) of cycle release schedule.
 +
** The following is the subject of Feature Freeze:
 +
*** Changing the default behavior/configuration.
  
−
== Devstack ==
+
* Patrole: Week R-3 (Hard StringFreeze) of cycle release schedule.
 +
** The following is the subject of Feature Freeze:
 +
*** Same as for Tempest.
  
−
DevStack maintains stable branches for all officially supported OpenStack releases.
+
== Project with release mode: cycle-with-intermediary ==
  
−
Git repository tags are also maintained for the OpenStack milestones as a quick reference.  These are typically used for jobs that need a relatively recent but unchanging DevStack for testing.  The timing of the milestone tags is not precise but will be within a day or two after the milestone releases are final.  The tags are pushed into Gerrit similar to most projects:
+
=== Tempest ===
  
−
    git tag -s <tag> <commit> && git push gerrit <tag>
+
* 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
 +
** Example:
 +
*** Intermediate release https://review.openstack.org/#/c/514873/2
 +
*** Cycle release –https://review.opendev.org/#/c/685401/
 +
*** EOL stable release – https://review.opendev.org/#/c/703255/
 +
* Step2: Push release tag to openstack/release repo
 +
** Example:
 +
*** Intermediate - https://review.opendev.org/#/c/688613/
 +
*** Cycle release- https://review.opendev.org/#/c/685406/
 +
* Step3: Add release notes page after release patch is merged
 +
** Example:
 +
*** Cycle Release- https://review.opendev.org/#/c/687123/
 +
* Step4: Add releasenotes page link in openstck/release
 +
** 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
 +
** Example: https://review.opendev.org/#/c/766770/
  
−
None of the other side-effects of typical Gerrit repo tagging will happen, no tarball, nothing.  This is only for tagging in the repo.
+
== Project with release mode: independent ==
  
−
=== Things to remember when creating a stable branch ===
+
Below projects are with independent release and not associated with OpenStack cycle release.
  
−
1. Hard code the tempest extension list. This is needed with branchless tempest to ensure we are only trying to test new extensions against master. This can be done with the verify-tempest-config script packaged in tempest. lib/tempest has examples on how to use it. See: http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/tempest?h=stable/juno#n303 for an example of a hard coded list.
+
* hacking
 +
** Example: https://review.opendev.org/#/c/715578/
 +
* os-testr
 +
** Example: https://review.opendev.org/#/c/713142/
 +
* bashate
 +
** Example: https://review.opendev.org/#/c/710560/
 +
* devstack-tools
 +
** Example: https://review.opendev.org/#/c/710561/
 +
* eslint-config-openstack
 +
** Example: https://review.opendev.org/#/c/785024/
  
−
2. Hard code the tempest Compute Maximum Microversion. This is needed with branchless tempest to ensure we are only trying to test new microversions against master. Stable branch must have Maximum microversion same as supported by Nova at that release. See: https://github.com/openstack-dev/devstack/blob/master/lib/tempest#L343-L346. To know maximum microversion supported by Nova at that release see (example of maximum version in liberty): http://docs.openstack.org/developer/nova/api_microversion_history.html#maximum-in-liberty
+
== Project with no release==
  
−
== grenade ==
+
Below projects are with no release and maintained as master version only.
−
Just like devstack grenade doesn't have publish releases or tags, but at each OpenStack release a stable branch needs to be created. Unlike grenade however there are also some updates that need to be made in repo to handle the new branch names for upgrading.
 
  
−
# The new devstack stable branch needs to be created. Without a stable devstack branch grenade won't have anything new to update from for master.
+
* coverage2sql
−
# The grenade stable branch needs to be created just like devstack
+
* devstack-plugin-cookiecutter
−
# The defaults in the new stable branch need to be updated for example see: https://review.openstack.org/129645
+
* devstack-plugin-open-cas
−
# Update the grenade master branch to upgrade from the newly created release to master and update the name of the working dev release. For example see: https://review.openstack.org/#/c/128959/
+
* devstack-plugin-nfs
−
# At this point devstack-gate needs to be updated so that the branches being update from and to are correct for all the gating jobs. For example see: https://review.openstack.org/#/c/128974/
+
* devstack-vagrant
 +
* karma-subunit-reporter
 +
* openstack-health
 +
* os-performance-tools
 +
* stackviz
 +
* tempest-stress
 +
* tempest-plugin-cookiecutter
  
−
== Hacking ==
+
= Projects with only Branches =
  
−
Versioning: http://docs.openstack.org/developer/hacking/readme.html#versioning
+
For the most part, Devstack and Grenade only have branches, which need to be cut when other projects get '''stable/*''' branches during a
 +
release.
  
−
Hacking has a branch for every major.minor release. For example: 0.9.x and 0.8.x. The process for cutting a new major or minor release involves creating a new branch and pushing a tag (major.minor.0). At that point patches that fit the versioning requirements can be backported to the stable branch for maintenance releases.
+
* Devstack
 +
** Step1: Wait for stable/* branch to exist on the projects in Devstack repo
 +
** Step2: Propose to openstack/releases to create a stable/foo branch for Devstack
 +
*** Example: https://review.opendev.org/#/c/685400/
 +
** Step3: Update .gitreview for stable/foo – patch from OpenStack Release Bot
 +
*** Example: https://review.openstack.org/#/c/647855/
 +
** Step4: Update branches for stable/foo
 +
*** Example: https://review.openstack.org/#/c/647867/
 +
** Step5: Update DEVSTACK_SERIES on master Devstack
 +
*** Example: https://review.opendev.org/#/c/687112/ 
 +
** Step6: Update lib/tempest to hardcode max microversions and extensions on stable/foo
 +
*** Example:
 +
**** https://review.opendev.org/#/c/687115/
 +
**** https://review.opendev.org/#/c/687176/
 +
** Step7: Update INSTALL_TEMPEST to False on stable/foo
 +
*** Example: https://review.opendev.org/c/openstack/devstack/+/774877
 +
** Step8: After Devstack has been branched. Add a new stable branch job in the Tempest pipeline.
 +
*** 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.
 +
*** Example: https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/810999
  
−
== eslint-config-openstack ==
+
* Grenade
 +
** Step1: Wait for stable/foo to exist on Devstack
 +
** Step2: Propose  to openstack/releases to create a stable/foo branch
 +
*** Example: https://review.opendev.org/#/c/686771/
 +
** Step3: Update .gitreview for stable/foo – from OpenStack Release Bot
 +
*** Example: https://review.opendev.org/#/c/686991/
 +
** Step4: Update the master grenade setting for stable/foo to master upgrade
 +
*** Example: https://review.opendev.org/c/openstack/grenade/+/785006
 +
** Step5: Update grenade setting in stable/foo
 +
*** https://review.opendev.org/c/openstack/grenade/+/785007
  
−
This project follows the release model of Hacking (above), with a branch for every major.minor release (ex: 0.9.x and 0.8.x). Please refer to the above for process and procedure.
+
* 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
  
−
To perform a release, please first install npm on your system. Then, perform the following steps:
+
* 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
  
−
    # Check out the most recent master.
+
Once all is done then you deserve to go for beer \o/
−
    git checkout master; git pull;
 
−
   
 
−
    # Ask NPM to update the package version, and tag the release.
 
−
    npm version (major|minor|patch)
 
−
   
 
−
    # Push the new tag to gerrit
 
−
    git push --tags
 
−
   
 
−
    # Request for a code review on the new version tag.
 
−
    git review
 
−
   
 
−
    # Ask NPM to publish the tag to npmjs.com
 
−
    # (This step will be deprecated by https://review.openstack.org/#/c/199725/)
 
−
    npm publish
 

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/

Retrieved from "https://wiki.openstack.org/w/index.php?title=QA/releases&oldid=183702"