Feature Overview

On operator upgrades provide more visibility into the support matrix.

Goals

As of today customer can upgrade the operator on the hub without any check on whether the hub cluster is on a supported OpenShift version after the upgrade.

In addition also there is no check whether the spoke clusters run on a supported version to be managed by the hub.

Requirements

Questions to answer

• ...

Out of Scope

• …

Background, and strategic fit

At the moment the following can happen. The customer upgrade the operator on the hub and it's no longer working as the hub doesn't have the required OCP version. The matrix https://access.redhat.com/articles/7073065 is quite complicated and there is no visual/textual hint that the customer will end in an unsupported config beside the fact that it may also just not work due to the version discrepancy. This is as well true for hub and also for spoke. 

Assumptions

• ...

Customer Considerations

• If we can add the support matrix as metadata to the operator we can either just simply show the info or even prevent the upgrade to be performed and first force the cluster being upgraded to a supported version.

Documentation Considerations

Questions to be addressed:

• What educational or reference material (docs) is required to support this
  product feature? For users/admins? Other functions (security officers, etc)?
• Does this feature have a doc impact?
• New Content, Updates to existing content, Release Note, or No Doc Impact
• If unsure and no Technical Writer is available, please contact Content
  Strategy.
• What concepts do customers need to understand to be successful in
  [action]?
• How do we expect customers will use the feature? For what purpose(s)?
• What reference material might a customer want/need to complete [action]?
• Is there source material that can be used as reference for the Technical
  Writer in writing the content? If yes, please link if available.
• What is the doc impact (New Content, Updates to existing content, or
  Release Note)?