Goal: Cluster admins and users deal with a single API to install Operators. Cluster users deal with a single object to discover and interact with Operators.

Benefits hypothesis: Easier interaction with OLM on the kubectl level. Easier troubleshooting. Better understanding of relationship between second level objects.

Why is this important: Though it deals with complex matters (make Non-Kubernetes-API-experts able to extend Kubernetes APIs) OLM needs to reduce the visible product surface in order to attract customers and Kubernetes users. Operator developers and users alike need a short route to success in getting their Operator deployed and tested. Not all use cases need the full blown catalog setup which is required as of today.
This will encourage short feedback loops for Operator developers, eventually increasing the velocity at which Operators are developed and updated, ultimately growing the ecosystem.

Requirements

Expected deliverables:

• an API called Operator used to install and discover Operator
• deprecation of separate OperatorGroup in favor of managing scope settings in the Operator API
• ability to install a single Operator bundle using the Operator API
• ability to install an Operator from a catalog using the Operator
• an Install API to implement Android-esque permission review model
• ability to use the Install API to discover Operators installed as dependencies
• ability to use an API to preview what would other Operators would installed by OLM as a result of dependencie resolution
• opt-in ability to force-fully install or update an already installed version, regardless of whether dependencies or update graph edges have been met
• opt-in ability to roll back failed updates in which case the operator developer / cluster admin ensures this is not causing data loss or CRD version conflicts
• ability to initiate operator deployments from lesser privileged users via a request/approval flow supported by privileged users