Operator Provisioner

Customer Problem: Operator Management UX

Actually installing operators with a single easy to use API is something that is difficult today for users. Most users consider the Subscription API to provide that functionality, but today that is limited to installation in the context of an upgrade path. Cluster Admins need a flexible but easy to use installation context to install operator bundles as they are defined today.

Goal: Provide a Provisioner controller for the existing registry+v1 operator bundles that are currently provided by operator index images in existing clusters.

Problem: With lower level building blocks available, we still need to actually implement a controller that can define the superset of workflows required to make the Operator API a writeable porcelain API that can satisfy the set of stories defined in https://issues.redhat.com/browse/OLM-1579

Dependencies (internal and external):

• RukPak https://issues.redhat.com/browse/OLM-2150
• Depster https://issues.redhat.com/browse/OLM-2151

Prioritized deliverables (in scope / not in scope):

1. Build a registry+v1/olm.bundle Provisioner and ProvisionerClass to provide install workflows needed for higher order Operator API. (in scope)
2. Build an approval plugin for operator bundles so that registry+v1 bundle instances can be approved by the operator api controller in the same way that the existing installplan approval workflow works for existing OLM versions

Estimate (XS, S, M, L, XL, XXL): L