OCP API Compatibility Policy

OpenShift and Kubernetes are strong because they use APIs for so many functions. This also means that the APIs will change over time as components are updated. Therefore, it is important to verify that an API call is still compatible with the cluster so that you will receive the desired response. Please review the documented section called “Understanding API Tiers”.

The most important thing to understand when considering which Z-release to upgrade to inside of a new Y-release is what patches need to be in the new Z-release. In other words if you are currently at OCP 4.11.28 you will need to make sure to upgrade to a Z-release of 4.12 that has all of the patches in it that were applied to 4.11.28, otherwise you will break the built-in compatibility of Kubernetes.

Support of specific API versions needs to be maintained by each cluster operator. With new releases of operators come new APIs. Therefore, the changes or skews in APIs need to be maintained. To a certain extent the APIs can be compatible across several releases of an operator. This list of operators and the releases that are compatible are at: https://kubernetes.io/releases/version-skew-policy

Can I choose any Z-release in the new EUS or Y-stream version? -NO The new 4.Y+2(or+1).Z release needs to have the same patch level that your currency 4.Y.Z release has.

Why does 4.14.1 not have the same patches as 4.12.45? All “new” patches are applied upstream first. This means that after 4.14.0 was release, 4.15 became the upstream version. For example: the way that patches are applied to new and old releases is with new z-releases so a patch that is applied in X.Y+2.4 might have also been applied to X.Y.36.

OpenShift upgrade process mandates that: If fix “A” is present in a specific X.Y.Z release of OCP Then fix “A” MUST be present in the X.Y+1.Z release that OCP is upgraded TO

You can use the upgrade graph tool to determine if the path is valid for your z-release. You should also always verify with your Sales Engineer or Technical Account Manager at Red Hat to make sure the upgrade path is valid for Telco implementations.