#helmfile (2023-09)

Helmfile’s environment values affect helmfile-only state. It’s not passed to helm releases as helm values. You may use

releases:
- name: ...
  ...
  values:
    ...
    - fromRelease: HelloFromRelease
    - fromEnv: {{ $.StateValues.fromEnv }}

to pass fromEnv as a helm value

Ok, thank you, it works perfectly.

This works but it is a little ugly:

{{ if .Values.prometheus.enabled }}
installed: true
{{ else }}
installed: false
{{ end }}

try to replace True into true.

Thanks @yxxhero. that seems to solve the problem!!!

use true .

I try to follow the example here:

https://helmfile.readthedocs.io/en/latest/shared-configuration-across-teams/

It doesn’t seem to work.

First the observability/helmfile.yaml is wrong on the example as it doesn’t have valid top level config key.

Add the top level key “releases:” solved the issue, but it complains about .Values missing some keys. It looks like the helmfile try to render the templates defined in the sub helmfile.

@Phil Chen please share your demo in github.

@yxxhero attached is my tests helmfile directory structure.

After you untar the tarball. cd helmfile/team/teamA helmfile lint -e dev

you will see the error.

I looks like the Environment values are not passed to the sub-helmfiles

Looks like it worked if I rename the “common.yaml” to “common.yaml.gotmpl”

It works on heimfile version 0.149, but not for the verision 0.156, a regress?

which part is not work in 0.156?

@Phil Chen

With 0.156, I had issue with complain about sub-helmfile missing top level config. If I add the top level config “releases: “, the complain went away, but it doesn’t render the template even with “.gottmpl” at the end of “common.yaml.gotmp”. With 0.149, it seems working okay.

any logs?

I take it back @yxxhero The 0.149 doesn’t work either. I had a typo in the gotmpl. It didn’t find the file and skipped. Hence it didn’t show error. I find out by example the resulted template results and verified that with debug enabled. Now, we are back to the square one: the shared common sub helmefile doesn’t work if it contains template as the environment .Values not passed in to the sub helmfile. The example shared helmfile in the documentation doesn’t use template, so that works fine.

Here is my example:

• name: kube-promethues-stack namespace: prometheus chart: premetheus-community/{{{{ .Release.Name}}}} version: 45.7.1 installed: {{ .Values.prometheus.enabled }} inherit:
  • template: default

As you can see it references {{ .Values.prometheus.enabled }} from Envrionment values.

The {{{{ .Release.Name }} }} is okay though

I guess the questions is there any way we can pass Environment values from the parent helmfile to the child helmfile?

Those k8s manifest is not s simple yaml file. They contains go templates just like a helm chart templates. I can see one way to do this is to create a helm chart, but reading document, the helmfile might be able to chartify them automatically.

I used helmify to create a local helm chart for the extras manifests–I wish there an easier and better way to do this. But anyway, after I created the chart in local directory: charts/my_manifest_local_chart, I added this to the helmfile

releases:

releases:

• name: my_app <<: *default namespace: my_ns chart: chart/my_manifest_local_chart

But I am getting this error:

ARGS: 0: helm (4 bytes) 1: fetch (5 bytes) 2: charts/my_manifest_local_chart 3: –untar 4: –untardir 5: /tmp/helmfilexxxx…./charts/my_manifest_local_chart/lastest

ERROR: exit status 1

EXIT STATUS 1

STDERR: Error: repo charts not found

Why it try to fetch a local chart?

if it is a lcoal chart. please use the format like “./”.

Thanks @yxxhero that worked.

Now, I am trying with a directory that contains yaml files. my understanding is that helmfile will chartify it. Are yaml files allowed to have go templates? The answer might be not? Then I guess is if that is not support, any possibility to add it?

People who like kustomize are those who doesn’t like template. people who like helmfile are those who are appreciate the power of templates it bring on table.

helm and kustimize represents 2 approaches for customize the k8s manifest for different deployment requirements. while kustomize is simpler to learn and easier to get started, helm brings in sharable package and releases concept which kustomize doesn’t have.

By supporting create a release from regular k8s manifest files and kustomize, helmfile bring the benefit of helm to the kustomize and ad-hoc k8s manifests.

Now, if we add options to allow template k8s manifest and kustomize, we would give use a very powerful tool to further blur the line btw the template and non template overlay approach, bridge the gap. For example, instead of writing a overlay for each env, we can write an overlay that contains simple go template and rendered by helmfile before it applies the overlay and creates the temporary helm chart.

@yxxhero do you think it makes sense to extend the helmfile to allow combine template and the kustomize?

@Phil Chen you can post a discussion in github.

Okay, will do. Thanks for the suggestion and much appreciated for your help!

@yxxhero here is the discussion: https://github.com/helmfile/helmfile/discussions/1023