Goal: Operator Developers can include any arbitrary kubectl-able resource manifest in their bundle and expect OLM to apply and manage it.

Problem: OLM-1582 enabled Operator Developers to build bundles without writing CSVs directly, but did not enable the inclusion of arbitrary resources, and did not remove the CSV from the final output artifact.

Why is this important: It's impossible to foresee all the use cases that Operator Developers have by shipping Kubernetes artifacts other than Deployments. Operator bundles should not limit the type of resources that could constitute an Operator and it should be seamless to use existing Kubernetes manifest to create a bundle. At the same time we would expect certain types of manifests to be part of the bundle to do necessary work (RBAC, ServiceAccounts, CRDs, etc).

Additionally, by including the CSV in the bundle (which is an OLM-provided type) we couple bundles to specific, supported api versions by OLM. By removing the bundle and relying on other metadata in the bundle, OLM will have more freedom to provide better on-cluster operator interfaces in the future.

Priortized epics + deliverables:

• A user can specify additional arbitrary Kubernetes manifests to be considered for installation
• OLM will offer limited lifecycle on additional custom objects at first (create/re-recreate only)
• OLM can offer more comprehensive lifecycle for custom objects (3-way merge)
• Users can configure the extent of lifecycle management OLM should offer to their additional manifests beyond initial deployment

Estimate: L

Note: All stories in this epic require review, the scope has changed (see current description) since the epic was created for 4.5.