Customer problem: Determine Operator Cluster Compatibility

Cluster admins always want to stay on the supported path. They need a clear signal from the cluster/Operator management software when they are about to leave that path. Especially with a new OCP release many Operators have not established support for the new version yet and the only way to find out is to scan all release notes. The problem compounds with the amount of Operators active on the cluster. 

Goal: Make cluster-admins aware that updating to a next OpenShift version could render an installed Operator incompatible. The platform can make recommendations on how to remediate incompatibility. Currently installed Operators can be verified to be supported with the current OpenShift version.

Why is this important: Optional OpenShift Add-On Operators (OLM-managed Operators) release independently of OpenShift. There can be situations in which an Operator is not yet updated to support a certain newer OpenShift version. Also, Operators might fall out of support for older OpenShift versions. Installing / Running an incompatible Operator might end up in the inability of new users to use the Operator. Updating the cluster to a version incompatible with the currently installed Operator might end up breaking production workloads.

Given this, customer need to be guided to stay the supported path for OpenShift and particular OpenShift Add-Ons Operators. Especially Updates should continue to be a casual exercise for the customer. They should not fear incompatibility arising with the update in regards to additional Operators they installed on the cluster. Providing clear communication about upcoming incompatibilities as well as remediation paths ensures the customer stay on the supported path and prevents them from entering an unsupported OCP <> Operator combination which might cause severe production outages.

Why does this need to be released in 4.8?

There will be a breaking API change introduced in 4.9.0: v1beta1 CRDs are removed. Many optional operators deployed by OLM still use v1beta1 CRDs.

In order to prevent an upgrade from 4.8 to 4.9 that results in breaking these operators, at minimum we need:

• A way for operator authors to signify which minor versions of OpenShift their operator is compatible with
• OLM to signal to CVO – the thing that controls cluster upgrades – when operators, incompatible with the next minor version of OpenShift, are installed on a cluster

Why can't this wait until 4.9 is released?

If 4.9.0 is released before 4.8.z has this feature, users might falsely assume it is safe to upgrade from 4.8 to 4.9 and end up with broken optional operators and data loss.

Required features:

• Operators compatibility with current and future OCP versions can be expressed by the Operator author
• OLM can determine whether or not a currently installed Operators is support (meant to be compatible) with the current OpenShift version and the next OpenShift minor version (e.g. currently 4.6, next is 4.7)
• Compatibility information is visible / can be previewed to cluster admins prior to the update
• Before OpenShift Updates the admin is warned about potential incompatibility of installed Operators with regards to the next OCP release
• OpenShift can recommend updates to installed Operators to remediate incompatibility with a future OCP release
• the solution should be something that 3rd parties can easily adopt using maintainer tooling from the OLM upstream project
• If the cluster is higher than the max OCP version, install resolution fails before the installplan is applied
• documentation for Red Hat Operator developers (https://docs.engineering.redhat.com/display/CFC/Delivery)