#helmfile (2021-09)

https://github.com/helmfile/helmfile

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

Alyson avatar

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

Sean S avatar

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

muhaha avatar

@mumoshu any chance to merge https://github.com/variantdev/vals/pull/56 ( and bump helmfile ) ? thanks

1
muhaha avatar

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

Joaquin Menchaca avatar
Joaquin Menchaca

Question about SweetOps ingress.nginx/helmfile.yaml (ref): • Why a privileged daemonset vs default deployment? Trade offs? • Why deploy external backend service vs. one that comes with the chart?
• Noticed defaultBackendService is specified, but cannot find it anymore in values.yaml. (ref and ref)

2021-09-27

batistein avatar
batistein

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:

  1. Installing cilium
  2. Installing Prometheus
  3. 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?
deasunk avatar
deasunk

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

Peter Aichinger avatar
Peter Aichinger

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!

Include transitive dependencies · Issue #1915 · roboll/helmfileattachment image

Hello! Imagine you have a set of services: serviceA which depends on serviceB which depends on serviceC. Also there's serviceD which has no relation to any other service. So in helmfile you wou…

GitHub - variantdev/dag: Topologically sortable DAG for Go with support for parallel itemsattachment image

Topologically sortable DAG for Go with support for parallel items - GitHub - variantdev/dag: Topologically sortable DAG for Go with support for parallel items

OliverS avatar
OliverS

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
Provide a means of setting .Chart.AppVersion during install or upgrade without editing Chart.yaml · Issue #8194 · helm/helmattachment image

A significant number of comments and requests from #3555 were to have the ability to set .Chart.AppVersion at install and upgrade time without having to download and repackage the chart. Those comm…

2021-09-30

HJ avatar

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?

Théo Larue avatar
Théo Larue

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)

Théo Larue avatar
Théo Larue

if you want your values to be propagated just add the file under your nested helmfiles values

Théo Larue avatar
Théo Larue

also for your overrides thing, this is all very confusing, why not just call those values the same?

Peter Aichinger avatar
Peter Aichinger

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).

helmfile/writing-helmfile.md at master · roboll/helmfileattachment image

Deploy Kubernetes Helm Charts. Contribute to roboll/helmfile development by creating an account on GitHub.

    keyboard_arrow_up