Checklist to prepare for a new minor version of OpenShift 4

  1. Read and summarize release notes

    Read the release notes. Look for things that affect how we use OpenShift. Ensure each change which impacts us gets addressed.

    Write a summary and add it to our release notes summary. Make note of changes that influence how the solution teams operate a cluster or how our users use their cluster. Keep only the two most recent versions and delete the older ones.

  2. Conduct upgrade

    Use an existing test cluster and upgrade it to the new version.

    The new minor might not show up in the list of available updates, even when setting the channel accordingly. If this is the case, set the cluster’s update channel to fast-<n-1> and update to the latest patch first. This is, amongst others, necessary, when there is no GA release for the new minor available yet. The first GA version of a new minor usually is 4.<n>.3.

    Instead of using an existing cluster, you can also set up one with version 4.<n-1> and then upgrade this one.

  3. Check compatibility of components

    Check if all core Commodore components[1] are compatible with the new version. Address all issues as necessary. If it’s straight-forward, directly create a fix. Otherwise, create a follow-up story to address the issue.

    The best way to find and address issues is to inspect an upgraded and or newly installed cluster using the new minor version. Things to look for:

    • API versions of resource types used

    • Alert rules

    • Logic which generates configuration based on the cluster’s OpenShift version.

      One component which definitely needs to be updated for a new minor version is openshift4-monitoring. Additionally, verify that alert rules defined by other components are still picked up by cluster monitoring.

    • Usage of deprecated or removed Kubernetes features

      For example, we needed to update component resource-locker to explicitly create ServiceAccount token secrets for OpenShift 4.11 / Kubernetes 1.24.

  4. If there’s changes with a potential impact on customer workloads (for example the switch to cgroupv2 as default in OCP 4.13), create a ticket to research these changes. The minimum amount of research for such a change should be to search the internet for <feature> problems or <feature> issues (or similar) and note any issues that other people have talked about. The research ticket should have roughly the following acceptance criteria:

    * We understand the impact of rolling out the change
* We understand how the change may impact customer workload
* The impact of the change is highlighted in the release notes created as part of step 1
* Follow-up tickets for the rollout are refined and estimated
** Per-customer tickets are created, if we believe it's necessary to inform customers ahead of the rollout

  5. Upgrade to a supported OpenShift Cluster Logging version on the upgraded cluster

    Usually you’ll want to upgrade to the latest OpenShift Cluster Logging version.

  6. Conduct install on all supported cloud providers

    Use the installation documentation to install a new cluster. Do so for each supported hosting provider. Update the documentation, Terraform modules, and used tools as necessary.

1. Core Commodore components are those included by the distribution openshift4 and its parent hierarchy levels.