9 messages
Questions and discussion around helmfile https://github.com/roboll/helmfile and https://github.com/cloudposse/helmfiles
Archive: https://archive.sweetops.com/helmfile/
Alysonover 4 years ago
Hi,
Does anyone remember what parameter is used for helm not to create a new secret every time he deploys?
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 Sean Sover 4 years ago
Hello All, I'm trying to
helmfile sync for charts reside in remote github from other client (Rundeck). It's getting stuck and timeout.muhahaover 4 years ago
@mumoshu any chance to merge https://github.com/variantdev/vals/pull/56 ( and bump helmfile ) ? thanks
Joaquin Menchacaover 4 years ago
Question about SweetOps
• Why a privileged
• Why deploy external backend service vs. one that comes with the chart?
• Noticed
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)batisteinover 4 years ago
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
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?deasunkover 4 years ago
Is below the correct approach for setting different values for dev, stage, prod etc.
environment values:
helmfile:
environment values:
app-one:
version: 2.0.0
app-two:
version: 2.0.0helmfile:
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 }}Peter Aichingerover 4 years ago
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!
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!
OliverSover 4 years ago(edited)
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
• the script edits the chart's
• 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_SHAHJover 4 years ago(edited)
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
# helmfile.yaml
# directory/helmfile.yaml
…while this doesn’t?
# envs.yaml
# helmfile.yaml
# directory/helmfile.yaml
Why is customThing for some reason not in the
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?