Chronological PTL guide¶

New PTL¶

• Update the nova meeting chair

  • https://github.com/openstack-infra/irc-meetings/blob/master/meetings/nova-team-meeting.yaml

• Update the team wiki

  • https://wiki.openstack.org/wiki/Nova#People

• Get acquainted with the release schedule

  • Example: https://wiki.openstack.org/wiki/Nova/Stein_Release_Schedule

Project Team Gathering¶

• Create PTG planning etherpad, retrospective etherpad and alert about it in nova meeting and dev mailing list

  • Example: https://etherpad.openstack.org/p/nova-ptg-stein

• Run sessions at the PTG

• Have a priorities discussion at the PTG

  • Example: https://etherpad.openstack.org/p/nova-ptg-stein-priorities

• Sign up for group photo at the PTG (if applicable)

• Open review runways for the cycle

  • Example: https://etherpad.openstack.org/p/nova-runways-stein

After PTG¶

• Send PTG session summaries to the dev mailing list

• Make sure the cycle priorities spec gets reviewed and merged

  • Example: https://specs.openstack.org/openstack/nova-specs/priorities/stein-priorities.html

• Run the count-blueprints script daily to gather data for the cycle burndown chart

A few weeks before milestone 1¶

• Plan a spec review day

• Periodically check the series goals others have proposed in the “Set series goals” link:

  • Example: https://blueprints.launchpad.net/nova/stein/+setgoals

Milestone 1¶

• Do milestone release of nova and python-novaclient (in launchpad only)

  • This is launchpad bookkeeping only. With the latest release team changes, projects no longer do milestone releases. See: https://releases.openstack.org/reference/release_models.html#cycle-with-milestones-legacy

  • For nova, set the launchpad milestone release as “released” with the date

• Release other libraries if there are significant enough changes since last release. When releasing the first version of a library for the cycle, bump the minor version to leave room for future stable branch releases

  • os-vif

• Release stable branches of nova

  • git checkout <stable branch>

  • git log --no-merges <last tag>..

    • Examine commits that will go into the release and use it to decide whether the release is a major, minor, or revision bump according to semver

  • Then, propose the release with version according to semver x.y.z

    • X - backward-incompatible changes

    • Y - features

    • Z - bug fixes

  • Use the new-release command to generate the release

    • https://releases.openstack.org/reference/using.html#using-new-release-command

Summit¶

• Prepare the project update presentation. Enlist help of others

• Prepare the on-boarding session materials. Enlist help of others

A few weeks before milestone 2¶

• Plan a spec review day (optional)

• Periodically check the series goals others have proposed in the “Set series goals” link:

  • Example: https://blueprints.launchpad.net/nova/stein/+setgoals

Milestone 2¶

• Spec freeze

• Release nova and python-novaclient

• Release other libraries as needed

• Stable branch releases of nova

• For nova, set the launchpad milestone release as “released” with the date

Shortly after spec freeze¶

• Create a blueprint status etherpad to help track, especially non-priority blueprint work, to help things get done by Feature Freeze (FF). Example:

  • https://etherpad.openstack.org/p/nova-stein-blueprint-status

• Create or review a patch to add the next release’s specs directory so people can propose specs for next release after spec freeze for current release

Non-client library release freeze¶

• Final release for os-vif

Milestone 3¶

• Feature freeze day

• Client library freeze, release python-novaclient

• Close out all blueprints, including “catch all” blueprints like mox, versioned notifications

• Stable branch releases of nova

• For nova, set the launchpad milestone release as “released” with the date

Week following milestone 3¶

• Consider announcing the FFE (feature freeze exception process) to have people propose FFE requests to a special etherpad where they will be reviewed and possibly sponsored:

  • https://docs.openstack.org/nova/latest/contributor/process.html#non-priority-feature-freeze

  • Note: if there is only a short time between FF and RC1 (lately it’s been 2 weeks), then the only likely candidates will be low-risk things that are almost done

A few weeks before RC¶

• Make a RC1 todos etherpad and tag bugs as <release>-rc-potential and keep track of them, example:

  • https://etherpad.openstack.org/p/nova-stein-rc-potential

• Go through the bug list and identify any rc-potential bugs and tag them

RC¶

• Do steps described on the release checklist wiki:

  • https://wiki.openstack.org/wiki/Nova/ReleaseChecklist

• If we want to drop backward-compat RPC code, we have to do a major RPC version bump and coordinate it just before the major release:

  • https://wiki.openstack.org/wiki/RpcMajorVersionUpdates

  • Example: https://review.opendev.org/541035

• “Merge latest translations” means translation patches

  • Check for translations with:

    • https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:zanata/translations

• Should NOT plan to have more than one RC if possible. RC2 should only happen if there was a mistake and something was missed for RC, or a new regression was discovered

• Do the RPC version aliases just before RC1 if no further RCs are planned. Else do them at RC2. In the past, we used to update all service version aliases (example: https://review.opendev.org/230132) but since we really only support compute being backlevel/old during a rolling upgrade, we only need to update the compute service alias, see related IRC discussion: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-08-08.log.html#t2018-08-08T17:13:45

  • Example: https://review.opendev.org/642599

  • More detail on how version aliases work: https://docs.openstack.org/nova/latest/configuration/config.html#upgrade-levels

• Write the reno prelude for the release GA

  • Example: https://review.opendev.org/644412

• Write the cycle-highlights in marketing-friendly sentences and propose to the openstack/releases repo. Usually based on reno prelude but made more readable and friendly

  • Example: https://review.opendev.org/644697

Immediately after RC¶

• Look for bot proposed changes to reno and stable/<cycle>

• Follow the post-release checklist

  • https://wiki.openstack.org/wiki/Nova/ReleaseChecklist

  • Add database migration placeholders

    • Example: https://review.openstack.org/650964

  • Drop old RPC compat code (if there was a RPC major version bump)

    • Example: https://review.openstack.org/543580

• Create the launchpad series for the next cycle

• Set the development focus of the project to the new cycle series

• Set the status of the new series to “active development”

• Set the last series status to “current stable branch release”

• Set the previous to last series status to “supported”

• Repeat launchpad steps ^ for python-novaclient

• Register milestones in launchpad for the new cycle based on the new cycle release schedule

• Make sure the specs directory for the next cycle gets created so people can start proposing new specs

• Make sure to move implemented specs from the previous release

  • Use tox -e move-implemented-specs <release>

  • Also remove template from doc/source/specs/<release>/index.rst

  • Also delete template file doc/source/specs/<release>/template.rst

• Create new release wiki:

  • Example: https://wiki.openstack.org/wiki/Nova/Train_Release_Schedule

Miscellaneous Notes¶