Feature Goal

• Provide a way for OLM Operators to be installed out of the box in OpenShift / by default as part of the cluster deployment using the OLM Subscription API
• Provide a way for those operators to lifecycle with the cluster (upgrade when the cluster is upgraded, participate in blocking cluster install/upgrade completion until they are installed/upgraded)

See the platform operator portions of

https://docs.google.com/document/d/1srswUYYHIbKT5PAC5ZuVos9T2rBnf7k0F1WV2zKUTrA/edit#heading=h.mduog8qznwz

https://docs.google.com/presentation/d/1U2zYAyrNGBooGBuyQME8Xn905RvOPbVv3XFw3stddZw

And this roadmap for platform operators:

https://hackmd.io/MFwDuS_XS7quls3Q4ANKLw

Why is this important?

• Several Operator teams are looking to be installed on OpenShift by default for a regular cluster deployment, e.g. cert-manager, ServiceBindingOperator, LocalStorageOperator
• This is an OpenShift Downstream ask, because the only other option to ship an operator with every cluster install would be to use CVO which does not allow opting out of cluster defaults without putting the cluster into an unsupported state

Use Cases

1. A way exists to configure which Operators should be installed by default that are not in the core payload (day0 operator) 
2. The list of available day0 operators is under Red Hat's control
3. Day0 operators should also be available via the regular OperatorHub catalogs
4. Users are allowed to uninstall such default Operators post-install
5. Users are allow to configure whether such Operators should be installed by default on Day 0 or not (opt-out)
6. A default Operator can temporarily prevent a cluster upgrade in case if its in a critical process
7. An OpenShift install is not considered complete until all of the day0 operators are installed
8. An OpenShift install is considered failed if any of the day0 operators failed to install
9. A default Operator can change versions as part of a cluster upgrade 
10. A default Operator can be uninstalled as part of a cluster upgrade
11. When a default Operator is removed  such that only the controller is removed, but not the CRDs nor CRs
12. It should be possible to control for Red Hat which version of the day0 operator gets installed / updated
13. It should be possible to control for Red Hat from which channel a day0 gets installed / updated
14. A default Operator needs to be mirrored as part of mirroring OpenShift Release Payloads to enable a cluster in disconnected environments
15. A default operator is directed to be installed but the required catalogs aren't available yet
16. A disconnected customer wants to rely on Operators installed by default 
17. A day0 operator failed to upgrade/install during a cluster upgrade/install and a cluster admins wants to troubleshoot why
18. A day0 operator is the process of being installed or upgrades and a cluster admins wants to observe progress

Day0 Operator Criteria

• must ship in all arches that OCP supports
•  

Acceptance Criteria

• The above user scenarios need to be achievable
• OpenShift clusters for self-managed installs ship ServiceBindingOperator by default via this mechanism
• It should be independent of the current OperatorHub API (which we are likely going to deprecate in the future)
• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• Downstream documentation

Dependencies (internal and external)

1. OpenShift installer needs to bundle desired day-0 operators in it's payload / default scaffolding of post-install manifests.

Potential Candidates for Day0 operators:

1. cert-manager
2. Servince Binding Operator
3. Local Storage Operator

Open questions:

1. Do we need a special catalog for day-0 operators? Should this be part of the payload vs. an optional component?
2. What happens during cluster updates?
3. Does this block cluster installs?
4. How are these operator's discovered for offline mirroring?
5. Who is ultimately in control of day0 operator updates? The customer or Red Hat?
6. Are day0 operators always auto-updating? Do we allow users to change that?
7. Do we need to consider how to create an aggregated status that includes both CVO and OLM operators? (i.e. something that aggregates both CVO's ClusterOperator and OLM's OperatorCondition)

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>