Checklist to prepare for a new minor version of OpenShift 4
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 three most recent versions and delete the older ones.
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
Instead of using an existing cluster, you can also set up one with version
4.<n-1>and then upgrade this one.
Check compatibility of components
Check if all core Commodore components 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
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-lockerto explicitly create ServiceAccount token secrets for OpenShift 4.11 / Kubernetes 1.24.
If there’s changes with a potential impact on customer workloads (for example the switch to
cgroupv2as 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> 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
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.
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.
openshift4 and its parent hierarchy levels.