Feature Goal

The ability to define such "profiles" for installations is definitely one of the intended benefits of the Composable Openshift story in general. (It would apply equally to "a set of platform operators to enable/disable" as it would to "a set of optional capabilities in the payload that should be enabled/disabled").

In fact the CVO capability feature already has a concept of capability sets, though today the only sets are basically "All on" and "all off", but other sets could be introduced. Whether(and how) the platform operator set should be coupled to the feature cap sets is something we'd want to think about.

That said, another goal here is to make it possible to define such profiles externally to the payload, so that a third party (another redhat product team, or an external vendor) can define their own profile by picking the caps+operators they want. So the starting point for an implementation in my mind would be a wrapper around the install-config that enabled/disabled the desired things, instead of hardcoding profile definitions into the installer (though we could have some predefined).

Have we considered the use of composable profile types: for example, a "disconnected" install which would exclude a pre-defined list of operators, such as insights, to name one.

This goal makes total sense to me, I'd note there's an overlap in goal here between I think what users may want for Device Edge - in some cases they may also want to generate a single image (versioned thing) that they transactionally upgrade to - their workloads included (or at least, some of them).

this should have https://issues.redhat.com/browse/OCPPLAN-9638 as a parent but Jira isn't cooperating.

Nevertheless I'm not sure at all that running a controller to just watch a singleton instance of the service to be installed makes sense as the work to by example installing the certificate manager is only needed one time. If now, we have an "installation" controller able to check what it is needed to be installed as day-0 (certificate manager, service binding, localstorage, ...), then that makes sense as only one controller should run on the cluster.

i'm starting to get confused about what controller you are taking issue with/trying to avoid running. Cert manager, service binding, and localstorage controllers are certainly not only doing things at installation time. And the platform operator controller itself is watching for new platform operators to install/uninstall/upgrade(as well as report status of) at any time, not just install time.

That said, and i'll let jlanford@redhat.com keep me honest... the Rukpak model for operator packaging (the next gen of operator packaging) will not actually require that "operators" (olm installable bundles, really) have any long running workload resource at all. So if you want to create an "operator" that just defines some static resources, but doesn't define a long running deployment/controller, you'd be able to do that. I think we'd want to talk through the use case and alternatives before doing it, but i believe it would at least be technically possible.

I fully agree with you bparees@redhat.com concerning the point that we need a framework for installing, upgrading, uninstalling, and reporting on the health of a workload/component.

Nevertheless I'm not sure at all that running a controller to just watch a singleton instance of the service to be installed makes sense as the work to by example installing the certificate manager is only needed one time. If now, we have an "installation" controller able to check what it is needed to be installed as day-0 (certificate manager, service binding, localstorage, ...), then that makes sense as only one controller should run on the cluster. 

OLM provides two fundamental things:

1) a framework for installing, upgrading, uninstalling, and reporting on the health of a workload/component
2) a pattern for running operators/controllers that can provision instances of operands and maintain/manage those operands

I think (1) is clearly necessary here.

With respect to (2) we have many "singleton" operators (not necessarily OLM ones) in OCP, pretty much the entire core product. We also have OLM based ones like ACM.

Just because you're only running one instance doesn't mean you don't need logic capable of configuring+managing that one instance.

What would your alternative proposal be for how to include services like cert manager in clusters as an optional component? Keeping in mind that "add it to the payload" is not a viable solution because it couples the lifecycle of cert manager to the OCP lifecycle and makes it possible for cert manager bugs to block the release of OCP.

I like the idea to provision a cluster with some `packages/services` like the competition do (e.g. Tanzu) and ideally the packages to be installed should be associated to a profile in order to deploy what it is relevant for a: Developer, Builder, Security Admin, ...

I doubt that using OLM would help here as by example it is completely irrelevant to install using an operator something like the Cert Manager as we only need one instance installed/cluster. This is the reason why I dont like so much to use operators when we have to provision a cluster with some services which are cluster-scoped (Certificate Manager, Vault, Service Binding, Tekton, .....).

i think this should be tied together with https://issues.redhat.com/browse/OLM-2513 all of which rolls up under https://issues.redhat.com/browse/OCPPLAN-7589

OpenShift GitOps is also a day0 candidate. The use-case customers raise is that they want to go from zero to a cluster that is up and ready and configured to sync configs from a Git repo to the cluster. In order to achieve that, OpenShift GitOps operator needs to get installed post-cluster-installation, and then the operator needs to get configured to achieve the outcome in this use-case. Note that just installing the operator wouldn't be sufficient in this case.