-
Feature
-
Resolution: Unresolved
-
Major
-
None
-
None
-
Strategic Portfolio Work
-
False
-
-
False
-
OCPSTRAT-288Improve the operator catalog user experience
-
50% To Do, 0% In Progress, 50% Done
-
0
Goal: Make it easy to understand the support lifecycle tier a certain operator is adhering to in the OpenShift Console.
Outcome: A visualization of the support lifecycle tier of an operator in the catalog view and operator details pane inside the OperatorHub UI.
Background: As part of OCPSTRAT-753 we are implementing a standardized set of lifecycle tier definitions that every Red Hat operator has to adhere to. These definitions will replace the custom lifecycle definitions most Red Hat operators currently have. Each support tier will have distinct guarantees as to what the user can expect from the operator in terms of update cadence, support longevity, release dates etc.
Why is this important: This OCP support policy page is something they have to look up consciously and we want them to be able to tell right from the OCP console which operators are on which support tier.
Definition of new annotations:
- a new list of infrastructure-related annotations is required, it will look like this
- features.operators.openshift.io/disconnected
- the meaning of these correspond to the existing annotations found in our documentation
- all these new annotations denote support for respective feature in boolean values, so either true or false
Examples:
- an operator that only supports disconnected but none of the other annotations:
features.operators.openshift.io/disconnected: true
- an operator that supports operating in a disconnected environment, in a FIPS-enabled cluster, allows to select certain TLS ciphers and can talk to AWS APIs using STS-based authentication via the CloudCredentialOperator
features.operators.openshift.io/disconnected: true
Deliverables:
- explanation of these annotations in the official product documentation
- explanation of these annotations in Red Hat-internal operator developer document
- update of any upstream documentation if necessary
- update of any validation tooling if applicable (operator SDK?)
- declaration of deprecation for old formats
- awareness among Red Hat operator / product developer teams to switch to the new annotation format