#helmfile (2023-08)
Questions and discussion around helmfile https://github.com/roboll/helmfile and https://github.com/cloudposse/helmfiles
Archive: https://archive.sweetops.com/helmfile/
2023-08-02
2023-08-04
2023-08-22
Hi forks! https://kcl-lang.io/docs/user_docs/guides/working-with-k8s/mutate-manifests/helmfile-kcl-plugin Let me introduce you to the helmfile KCL plugin, which allows you to write KCL code in helmfile.yaml to edit or validate existing help charts. In addition, KCL is a configuration language mainly targeting Kubernetes scenarios, and its documentation is here. Welcome to provide feedback
Helmfile releases define a chart and a version. For those of you who use a single helmfile across multiple environments (dev/prod for example), how are you managing your chart between environments? As an example, dev and prod might both use chartA at version 0.1.0. When chartA is updated by the chart maintainer to 0.1.1, you may want to test 0.1.1 on dev but not on prod. How do you handle this case? One possible solution is using go templates in the helmfile.yaml, i.e.
- name: my-release
namespace: my-namespace
chart: chartA
{{ if prod }}
version: 0.1.0
{{ else }
version: 0.1.1
{{ end }}
(it is not valid syntax, but you get the idea)
Does anyone use a solution other than that? If so, can you describe your solution?
you can try to set a value in environment values. example chart_version: <verison>,
- name: my-release
namespace: my-namespace
chart: chartA
version: {{ .Values.chart_version }}
That’s how we do it as well. I find it cleaner. Is just that we add a default value there, in case is not defined, so that on prod you get the “well established” default chart, and in dev you can experiment, then you just change the default.
have you tried with a ternary similar to:
{{ ternary .Values.stable_version .Values.dev_version (eq .Values.env "prod")}}
2023-08-23
2023-08-25
Hello, We are trying to understand how we can override the helm values. For example, we have a helmfile like this declared in the components: releases:
- name: kyverno namespace: kyverno labels: kubernetes.io/metadata.name: kyverno chart: kyverno/kyverno version: 2.6.5 values: - kyverno_values.yaml
And then in the kyverno_values.yaml: podLabels: domain: appli productname: kyverno
How can we modify the labels with stacks? We tried like this but with no efect:
components: helmfile: kyverno: vars: podLabels: domain: test productname: kyvernotest
We would like to apply the modified lables when we install the kyverno for that stack “ atmos helmfile apply kyverno -s dienv”
could you post a demo? thanks.
2023-08-26
2023-08-29
Is there a reason the roboll/helmfile repo isn’t archived? That would fix SEO and prevent people creating new issues in the wrong repo
Yes, it’s a long one, read linked ticket in roboll/helmfile readme
as of why, you can ping roboll, who isn’t very responsive
Nothing conclusive in the linked ticket. Seems like the new maintainers are asking for it to be archived.
Nothing conclusive
That’s your answer
Yea, it’s odd to me why Roboll hasn’t taken any active interest in the project he created, despite not being actively involved. Anyways, it’s of course his choice. Also, no one else has the rights to update the repo settings. He’s the only admin.
I don’t understand the rationale for updating the readme to say the repo is dead and links to the new repo, but refuses to archive.
Code changes, including readme can be done by maintainers with push access. Archival can be done only by owner. There is single owner of this repo, who isn’t willing to do so
who isn’t willing to do so
Is that opinion made publicly anywhere? Or just back channel communication? Obviously he can do whatever he wants. I was just looking for the specific reason
No mention of archive. Perhaps that point wasn’t understood. I’ll try contacting him.