#helmfile (2021-09)
Questions and discussion around helmfile https://github.com/roboll/helmfile and https://github.com/cloudposse/helmfiles
Archive: https://archive.sweetops.com/helmfile/
2021-09-16
Hi, Does anyone remember what parameter is used for helm not to create a new secret every time he deploys?
sh.helm.release.v1.myhelm-1572515128.v1
2021-09-23
Hello All, I’m trying to helmfile sync for charts reside in remote github from other client (Rundeck). It’s getting stuck and timeout.
2021-09-24
@mumoshu any chance to merge https://github.com/variantdev/vals/pull/56 ( and bump helmfile ) ? thanks
i need to use:
values:
foo: secretkey: ref+file://{{ requiredEnv "SECRETS_PATH" }}#/bar/for
and
sops exec-file secrets.enc.yaml 'SECRETS_PATH={} helmfile template'
which can work only in linux
surprisingly:
values:
foo: secretkey: ref+file://{{ .Values.dynamicfile }}#/bar/for
and
sops exec-file secrets.enc.yaml 'helmfile template --set dynamicfile={}'
or
sops exec-file secrets.enc.yaml 'helmfile --state-values-set dynamicfile={} template'
is not working…
2021-09-25
2021-09-27
Hi guys, I have the use case that I need to upgrade a release in the helmfile, because some dependencies are only added on a later stage, but these are also depending on the previous step so I cannot solve it by changing the installation order. Here an example for the use case:
- Installing cilium
- Installing Prometheus
- Upgrade cilium - now with serviceMonitor enabled
What is the best way to do it?
I tried to specify the release a second time then with enabled serviceMonitor but I’m getting the following error
there are 2 releases named "cilium" matching specified selector. So I think it’s not possible to specify the same release twice?
Is below the correct approach for setting different values for dev, stage, prod etc. environment values:
app-one:
version: 2.0.0
app-two:
version: 2.0.0
helmfile:
bases:
- environments.yaml
---
releases:
- name: app-one
namespace: default
chart: repo/app-one
version: {{ .Values.app-one.version }}
- name: app-two
namespace: default
chart: repo/app-two
version: {{ .Values.app-two.version }}
2021-09-29
Hello everybody! I hoped someone here could help me with: https://github.com/roboll/helmfile/issues/1915 as I’m not getting any responses on github. In the meantime I also checked the DAG implementation helmfile uses and from reading the examples (https://github.com/variantdev/dag#examples) it should be able to calculate transitive dependencies, however helmfile doesn’t seem to pick them up… Grateful for any hints!
The issue with helm and appversion has not been addressed yet so meanwhile, since this topic comes up every so often, I thought I would post here what I do using helmfile:
• use a helmfile prepare hook that calls a script:
- name: your-chart
...
hooks:
- events: ["prepare"]
showlogs: true
command: "./set-helm-chart-appversion.sh"
• the script edits the chart’s appVersion in-place; eg on mac the script contains:
COMMIT_SHORT_SHA=$( git rev-parse --short HEAD )
sed -i '' -E -e 's/^appVersion: .*/appVersion: "'$COMMIT_SHORT_SHA'"/g' path-to/Chart.yaml
echo app version set to $COMMIT_SHORT_SHA
2021-09-30
Hello everyone! I’ve been trying to wrap my head around a fairly specific question, which I suppose has to do with the order of operations that happen with helmfiles, value files, go template resolution, etc. So, here goes:
Why does this work:
envs.yaml
customThing:
key: 'value'
helmfile.yaml
bases:
- envs.yaml
---
helmfiles:
- path: directory/helmfile.yaml
values:
- override: {{ if (index .Values "customThing") }}{{ .customThing | toJson }}{{ end }}
directory/helmfile.yaml
releases:
- name: myrelease
…
values:
- myvalues.yaml
- {{ if (index .Values "override") }}{{ .Values.override | toJson }}{{ else }}nothing: "here"{{ end }}
…while this doesn’t?
envs.yaml
customThing:
key: 'value'
helmfile.yaml
bases:
- envs.yaml
---
helmfiles:
- path: directory/helmfile.yaml
directory/helmfile.yaml
releases:
- name: myrelease
…
values:
- myvalues.yaml
- {{ if (index .Values "customThing") }}{{ .customThing | toJson }}{{ end }}
Why is customThing for some reason not in the .Values object in the latter example when directory/helmfile.yaml is rendered (even though it is in the very first file applied, envs.yaml), but when adding a key with those contents in the main helmfile.yaml, it can then be accessed under that key in the directory/helmfile.yaml?
well maybe it simply means that values are not transitive across helmfiles, which is by design. according to the doc the way nested helmfiles work is that the nested files are played first, and then the calling helmfile is played afterwards, but the files are not linked whatsoever (at least not implicitely)
if you want your values to be propagated just add the file under your nested helmfiles values
also for your overrides thing, this is all very confusing, why not just call those values the same?
I just experimented a bit. Looks like the docs are a bit inaccurate. I think values files in the bases: -section can really just merged into a helmfile when the values already exist in that helmfile. I’m not sure, but to me this looks in deed like a bug, as this can hardy be called a “merge” operation. Probably the use cases for its implementation were just for overrides of values which are always present (like the environment example in the docs: https://github.com/roboll/helmfile/blob/master/docs/writing-helmfile.md#layering-state-files).