search

open-cluster-management-io / community

open-cluster-management governance material.
https://open-cluster-management.io
Apache License 2.0
62 stars 23 forks source link

Proposal: Simplify Operator-based install process #146

Open gurnben opened 2 years ago

gurnben commented 2 years ago

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:

Downsides

Downsides include:

Alternatives

mikeshng commented 2 years ago

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

@qiujian16 @yue9944882 what do you guys think?

yue9944882 commented 2 years ago

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.