Should we provide non-porter based installation options for the operator?

[carolynvs]

Should we give people a way to install the operator without using Porter, such as with a helm chart (below) or using kustomize files directly themselves.

Questions about shipping a helm chart

The manifests that come out of kubebuilder/operator-sdk are all written for kustomize. I'm not sure if we can generate them as-needed (when we change rbac, add resources, etc) instead of regenerating them on every build, and then add in helm templating? Otherwise the helm chart won't have the standard set of features that we expect of helm, since it won't use variables at all.

Right now the operator's bundle uses kustomize to set the manager's image reference dynamically before installing it, so that it uses the manager image distributed with the bundle.

I wonder if we can use kustomize itself to replace values with templates and then make a workable helm chart that way? 🤔

Document how to install without porter

Ship the kustomize files in the release assets and then provide documentation that explains how to run them to install the operator.

The bundle also does a lot of customization/setup so ideally it would also explain that there's more setup to do and what to read to understand how to create additional config, like AgentConfig files (i.e. explain setupNamespace custom action on the operator bundle)

[squillace]

Some background to this PR, which is SADLY not a Carolyn pr anymore. :-(

My argument for helm, bundle, and Kustomize supported operator installations available for anyone to use is as follows.

1. Carolyn was THE person who believed in inclusion, and for her that was a human, not merely a software principle. I believe this PR indicates that she herself, though she didn't use helm to install, wanted any helm user to be able to walk up and install and test out the porter operator before they mastered either Porter or Kustomize or any other specific tool.
2. Abstractly, Helm is the single largest deployment and packaging tool in the Kubernetes ecosystem. Per the 2022 CNCF survey data (the latest we have -- https://blog.palark.com/cncf-cloud-native-projects-usage-stats-2022/) Helm is between 45% and 60% of a combination of deployment and packaging tools, down from roughly 75% IIRC in 2021.

It seems clear that Kustomize is becoming more used during this period, likely as a result of being directly integrated into kubectl as a plugin, but helm continues to outstrip it by wide margin, about 2.5x as much usage. My argument is that having a maintained helm chart to install the operator is pure usability and aids the "getting started" operator user.

None of this, per #217, requires a) the chart or kustomize files to reside in the same repo (though this is a common approach) and b) none of that requires any specific person who doesn't use it to be forced to maintain it. I'll bring this argument to the community discussion today.