Proposal: Simplify Operator-based install process

[gurnben]

Problem Statement

The interactive install process for open-cluster-management is cli-based, straightforward, and includes integrations support, but the operator-based (and potentially declarative) install process only includes core components, namely the cluster manager and klusterlet agent. For any user running an operator-based install, they still need to manually enable integrations via the CLI to gain those additional functionalities. This type of user (myself included) would like to deploy the hub and/or managed components alongside the integrations via OperatorHub declaratively and have OLM manage the lifecycle, including upgrade, of those components. For the Operator user, this also has the potential to simplify the install process!

Proposed Solution

Other projects that follow a similar operator install model typically bundle multiple operators under one "Operator of Operators". This "Operator of Operators" might include multiple Custom Resource Definitions, one being the Cluster Manger, but also include other CRDs to define our Addons/Integrations that can be deployed on the hub. When the "Operator of Operators" updates, it would cause the affected/upgraded CRs to carry out an upgrade process, managed by OLM. A good example of this process (although more complex and less itemized than an operator I would propose for o-c-m) is the multiclsuterhub-operator in the stolostron project which actually integrates some if not all of o-c-m.

This could also just be an extension of the existing Cluster Manger operator with additional CRDs that define policy and application integrations.

In this case, the user can still get the core functionality managed by OLM using the Cluster Manger, but also enable integrations by creating an additional CR (which can be created declaratively).

Benefits

This provides a few benefits, namely:

• Declarative install of Cluster Manger and Addons/Integrations
• Potential for automatic upgrade of Cluster Manger and Addons
• "one click" install experience for OLM users
• ...

Downsides

Downsides include:

• Feature presents no value to non-OLM-users
• Dual-maintenance of two deploy methods
• Additional coordination efforts to ensure that new Addons/Integrations can deploy via the operator
• ...

Alternatives

• Continue to use the current model and users can build automation to deploy a hub + managed components
• Build a "GitOps" repo that contains the resources created by clusteradm for the hub and integrations/addons deployments that can be delivered declaratively/using kustomize or a GitOps model of your choice
• Build helm deployables for these components

[mikeshng]

I think this is a good idea to attract more OCM end users.

@qiujian16 @yue9944882 what do you guys think?

[yue9944882]

i was also looking for declarative approach to install OCM hub & spoke previously. a good way i can think of is packing the OCM core components into helm charts (note that now we have a central chart registry at https://github.com/open-cluster-management-io/helm-charts).

additionally, i think it's also valuable to have an auto-approved registration option along w/ the declarative installation, e.g. in some cases we may want set up a vanilla test sandbox environment easily, otherwise we will always have to orchestrate the registration process repeatedly. (that's why i proposed & added --wait flag to the clusteradm binary for the test github action). additionally this will also be helpful for third-party community projects to build integration to OCM. e.g. previously i built a kubevela addon for helping users to try out OCM smoothly in an existing kubevela environment, but the progressive registration process is kind of making it difficult b/c a kubevela addon is just made up of a few static yamls, i can't automatically install registration agents for their managed clusters from there. so the addon is staying at merely installing hub components for their users.