Feature Request: Use the same values.yml for the 3 charts about helm-charts HOT 5 CLOSED

Personally, I think having 1 joint values.yaml is the way to go. Thinking about dealing with several charts to be installed that depend between themselves, I see myself doing helmor hypper installs like: hypper install -f joint-values.yml kubewarden-defaults (which would install needed versions of cert-manager, crds, grafana, .. and controller if needed and in the right order), or just several helm install -f joint-values.yml kubewarden-controller; helm install -f joint-values.yml kubewarden-defaults.

from helm-charts.

I was asked my opinion so here goes...

Who are the intended users of the charts and what experience do they need? You and I aren't the target user. I'm going to guess that there are 3 target users here.

1. Developers you want to install KubeWarden. These are not ops people. They want something simple to install (copy and paste instructions?). Maybe this is someone who wants to write and test policies.
2. Operators who take the charts and use them with Helm in a configuration manager to run them in an environment. The charts may be paired with something like Helmfile or Flux.
3. This may be 2a; those who want to make the chart work in the Rancher catalog

The 1 target user is the person who I would not expect to be a Kubernetes expert. 2 and 3 are going to be people who know Kubernetes and possibly Helm.

I would optimize for the experience of the first target audience. To make their experience as easy as possible. Both in the docs and in the flags they set or YAML they use.

With that in mind... the following should just work...

helm install kwc kw/kubewarden-controller
helm install kw kw/kubewarden-defaults

Note, I used the name kwc and kw. In the real docs this could/should be expanded. Should the namespace be set, too?

To follow this experience for users, if there is a custom configuration file it would be nice if it was consistent.

helm install kwc kw/kubewarden-controller -f myvalues.yaml
helm install kw kw/kubewarden-defaults -f myvalues.yaml

What should the layout of this values file look like? The roles 2 and 3 can deal with some more complex variation and things that require Helm knowledge. But, the first role (the developer) might be confused by some of that. So, I would make the values you expect them to override to be as flat as possible. Not under global and not with lots of nesting. Don't make them think or have to learn much about Helm.

I realize you need a certain level of Kubernetes knowledge to write useful policies in KW. What level of that is needed? Can it be someone who knows just enough from the docs or stack overflow?

Just thinking out loud.

from helm-charts.

Context: #70 is doing a slightly different approach, (C) as opposed to (A) and (B) on this issue description.

(A) Have a toplevel values.yaml with all components in globals:

global:
  kubewarden-controller:
    ...
  kubewarden-defaults:
    ...

This implies having no specific values.yaml per chart. All settings are on the toplevel values.yaml file, in the global section.

(B) Merge values from different charts in a global values.yaml in an automatic fashion.

(C) Each chart has its own values.yaml with things specific to that chart. A toplevel values.yaml exist that contains only the settings that might be used by more than one chart. This settings are exposed in a global section in this specific toplevel values.yaml.

From my point of view, (B) requires some automation or some work to be done in order for the merging to happen, I would not go right away with that one. (A) creates a single values.yaml and all usages of those values on charts will need to be prefixed (e.g. .Values.global.<chart-name>.X.Y.Z for the majority of usages, being slightly more verbose). I think (C) is a good middle ground because each chart maintains its own values.yaml, and it's very explicit what kind of thing it needs to sync with other charts, given those variables will be accessed as .Values.global.X.Y.Z, and only those.

from helm-charts.

The full global values approach of (A) is only needed for subcharts. But I suppose we will not pursue subcharts, given that then we are back to init containers for waiting on parts of the stack to be up, and we will need to put the crds in a crd/ folder in the controller chart. To be honest I dislike both, and they are some of the shortcomings that brought the creation of Hypper.

(B) is indeed automation heavy for little gain. I would prefer the automation to be in the chart release part, and not for the user.

(C) is ok, but I dislike that a user needs to track 4 values.yml files (and keep them in sync).

I would like to merge (A) and (C) into (D).

(D): we only expose 1 kubewarden-values.yml file to users. That kubewarden-values.yml has variables:

• global.foo.bar: that affect more than 1 chart at the same time (we can add a 1 line comment stating so)
• baz.fiz: that affect just 1 chart.

We will need a bit of automation on the helm-chart repo (I suppose just having 1 kubewarden-values.yml file in the root, that gets copy-pasted to all the charts/* subfolders before tests/release).
If a user is just deploying 1 chart, the kubewarden-values.yml will work fine, Helm just ignores unused variables. If they deploy several, it will all work. It also works with Hypper, too.

from helm-charts.

Both C and D approaches are good and I'm happy with any of those. However I think the C approach is a bit easier for the end user. In my opinion it is easier for the user to see which attributes are affecting each chart if they all have their own values.yaml, and we can use the global values for shared attributes such as the policy server name.

If we don't add a prefix to all attributes it is not very clear if this gets applied to the controller or the default policy-server. In addition to that, values.yaml might end up quite big if we keep adding attributes to the three charts.

from helm-charts.