Investigate removing helm as the primary installation templating tool

[timflannagan]

Feature Request

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Example: "I have an issue when (...)"

OLM currently uses helm solely for it's templating functionality and none of the lifecycle features that it provides. This may be an opportunity to re-evaluate whether we'd like to continue utilizing the helm chart templating to configure OLM installations locally and in CI, vs. a dedicated templating tool, like kustomize, jsonnet, cuelang, etc.

Describe the solution you'd like A clear and concise description of what you want to happen. Add any considered drawbacks.

[yelhouti]

Many people https://github.com/operator-framework/operator-lifecycle-manager/issues/829 asked for the release of the helm chart. Many of us try to automate cluster installation..., and many gitops tools use helmfile ... It would have been great if I could have added the chart to init my cluster... Please reconsider

[sboardwell]

@timflannagan, just out of interest:

• is there a current best-practice as to automated installation of OLM (per GitOps or otherwise) as opposed to manual installation?
• what would the alternative be if a helm chart is not used?

@yelhouti: helmfile supports kustomize projects through hooks. Might be something to use.

Either way, it would be nice to have a documented best-practice wrt automating an installation.

[timflannagan]

@sboardwell I'm not aware of any best practices around installing OLM at the moment. It looks like most of the installation is centered around an installation bash script, so I'm sure there are better ways to expose an installation route to OLM. I was mainly getting the balling rolling on cleaning up a part of the repository that hasn't been re-evaluated since the creation of this project and whether it makes sense to remove this dependency given most of the functionality OLM uses it for can be replicated using the Go embed package and another templating tool entirely (e.g. kustomize).

It looks like there's a decent amount of interest in having OLM support a official helm chart when poking around the other issue tracking that work. I don't have any strong opinions on that front, but maybe @kevinrizza @ecordell have an idea on whether this is something the maintenance team has the capacity to maintain in the future.

[exdx]

So there are two issues at play here regarding helm:

• OLM uses helm under the hood to template manifests when creating a release. In this case helm can be removed for another tool, or adding it to the base Dockerfile. The benefit would be not vendoring helm in as a dependency, but the behavior would effectively be the same.
• Providing an OLM upstream helm package for users to install, versus manual installation via the scripts or operator-sdk olm install [1]. It's not entirely clear what the benefit would be, since the OLM manifests are configured before being released. This would be great, but has a large maintenance burden. Because there is so little to configure for OLM at install time, it's probably better to make that runtime configurable in the project versus via templating.

[1] https://sdk.operatorframework.io/docs/cli/operator-sdk_olm_install/#operator-sdk-olm-install

[yelhouti]

@exdx many companies aim to have zero manual configuration for reproducibility purposes, and to reduce disaster recovery downtime and human errors. you can read more about the topic of configuration as code (or infrastructure as code) in this article.

In our case, we have a helmfile project with all what is installed in our cluster, and it allows us to spin up a new cluster in minutes, this project is also easy to read, maintain and configure.

Without the helm chart, manual steps or unreliable hooks might be required, this is why I argue against this change.

[sboardwell]

Hi all,

@exdx - would it be possible to use kustomize with a kustomization.yaml as a deployment method? I am using something similar with the https://github.com/keycloak/keycloak-operator/blob/12.0.1/deploy/kustomization.yaml

Using https://github.com/vmware-tanzu/carvel-vendir to pull the sources, and helmfile's support for kustomize to create a pseudo helm chart which helmfile then manages.

[stoupance]

@exdx just a follow up for the idea of @sboardwell regarding a kustomization.yaml file as a deployment method. Based on documentation (https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/install/install.md), it could be something like:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- deploy/upstream/quickstart/crds.yaml
- deploy/upstream/quickstart/olm.yaml

Even though, this directory (deploy/upstream/quickstart) hasn't been updated with version v0.19.1 of crds.yaml and olm.yaml files.

Thanks.

[joaomlneto]

Not adding much to the conversation, but I also vote 👍🏻 keeping the Helm chart. I'd also vote for it to be automatically published in a standard helm repository for easy installation.

The provided script is not ideal for all use-cases. For example:

• We use Terraform to provision and configure Kubernetes clusters, and installing OLM is a pain. This exists, but it basically is a suboptimal workaround for this exact problem (as stated in their README).
• Using ArgoCD to deploy the OLM is also overkill in my opinion.

(If you have any ideas on how to install OLM in a clean way in Terraform, please let me know!)

If you consider reversing the decision to kill the chart, I'm happy to try and help with the chart and the publishing process! Just let me know if/how I can be of any help! 😄

[batistein]

For all those using helmfile. You can very easily integrate the current not released helm chart with: url: git+https://github.com/operator-framework/operator-lifecycle-manager@deploy/chart?ref=v0.22.0&sparse=0