search

bjw-s / helm-charts

A collection of Helm charts
https://bjw-s.github.io/helm-charts/
Apache License 2.0
524 stars 98 forks source link

Why is the main controller section commented ? (common library values.yaml) #301

Open briksys opened 3 months ago

briksys commented 3 months ago

Hello,

First, I can't thank you more for your huge contributions to the k8s / helm / flux / ... communities !

But I don't know what is the rationale for the main controller section to be commented out in the values.yaml ??

This is the case since 3.0.0-beta1. The main use case for using the template is to run at least one controller/pod ? And the very minimal required actions for using the common library should be to fill repo/tag/port, not to uncomment 250+ lines (even if with the correct VIM key sequence it's quite fast =D).

bjw-s commented 3 months ago

Hi, thanks for the nice words and raising this question!

The main controller/service/ingress sections in the values.yaml file are commented out for several reasons:

  1. In earlier versions, default (main) objects were included within values.yaml file. However, these defaults were obscuring some of the actual behavior of the Helm chart. Commenting them out provides clarity on what configurations are essential for the chart's functionality versus what are examples or placeholders.

  2. Instead of outright removing the default objects, they've been commented out to serve as illustrative examples. This approach allows users to reference them as templates or starting points for their configurations without causing interference with the chart's behavior.

  3. app-template is designed as a framework for deploying applications lacking their own Helm chart. By commenting out the main controller section, it allows users to customize and configure this section according to their own specific requirements of the application being deployed.

In most cases there is no requirement to "uncomment 250+" lines. My most complex set of values (with multiple controllers and services) is only 137 lines.

briksys commented 3 months ago

Thanks for the clarification, those 3 reasons are now clear to me. (And by the way I recently had an issue in 2.X while trying to rename one of those default objects !)

I still have a concern though, as for a beginner in helm chart/libraries (that I was some time ago...), It was very convenient to use the values.yaml file that we had until 2.6, to start testing new apps quickly. Because the file allies both most (all?) the possible attributes with explanations and references and the default objects. So this is why I mentioned that now I (or other people discovering the framework) will need to uncomment those lines if they want to keep the structure of this very "valuable" file, in order to have quick win deployments, and later spend the time to understand the library features and finally simplify the values.yaml.

Maybe it's possible to have a full-featured-values.yaml (somewhere in common or apptemplate) with both attributes documentation & the default objects. And keep the values.yaml (or even strip the documentation that will otherwised be maintained twice) ?

joelmccoy commented 2 months ago

I would also see some value in having some sort of full-featured-values.yaml file. I appreciated the pre 2.6 default values to get apps running quickly.