#helmfile (2023-04)

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/

2023-04-05

2023-04-10

Ivo avatar

What is the best way to check for a directory existence in a helmfile.yaml template? Value files can be safely ignored if they don’t exist, but I have a use-case for conditionally including a chart folder. And if that folder doesn’t exist, the release will fail.

Ivo avatar

I currently have this little snippet but it’s failing for me with the following error: can’t evaluate field Environment in type fs.DirEntry

{{ range $index,$item := readDirEntries "./policies" }}
{{- if eq $item.Name .Environment.Name -}}
- name: policies-{{ .Environment.Name }}
  chart: ./policies/{{ .Environment.Name }}
{{- end -}}
{{- end -}}
voron avatar

What about $.Environment.Name ?

Ivo avatar

Same issue unfortunately

Ivo avatar

Somehow it doesn’t recognise the different scope

Ivo avatar

@voron any idea what the issue could be, or protectively a wholly different approach?

voron avatar

Well, I have a working dirty sample

environments:
  dev:
---
releases:
  # always remove these releases
  {{- range $_, $file := ( exec "bash" (list "-c" "cd values-bots-to-remove;echo -n *.yaml") | splitList " " ) }}
  {{ $releaseName := trimSuffix ".yaml" $file }}
  - name: {{ $releaseName }}
    chart: xyz-{{ $.Environment.Name }}
    installed: false
  {{ end }}

And the output is

helmfile -e dev list
NAME                    NAMESPACE       ENABLED INSTALLED       LABELS  CHART   VERSION
bot                                     true    false                   xyz-dev  

Maybe

---

after environments is what you’re missing inside helmfile ?

Ivo avatar

I do have the —

Ivo avatar

Would you mind putting an if eq statement in there, like I have?

Ivo avatar

And see if it picks up on the $

Ivo avatar

I didn’t try using the $.Environment.name on its own, I’ll do that now

Ivo avatar

It seems to trip specifically on the if statement it seems

Ivo avatar

Using it in isolation, like in your example, does work

voron avatar

I don’t have issues using $.Environment.name inside if too

environments:
  bot:
---
releases:
  # always remove these releases
  {{- range $_, $file := ( exec "bash" (list "-c" "cd values-bots-to-remove;echo -n *.yaml") | splitList " " ) }}
  {{ $releaseName := trimSuffix ".yaml" $file }}
  {{ if eq $.Environment.Name $releaseName }}
  - name: {{ $releaseName }}
    chart: xyz-{{ $.Environment.Name }}
    installed: false
  {{ end }}
  {{ end }}

and the output is

helmfile -e bot list
NAME    NAMESPACE       ENABLED INSTALLED       LABELS  CHART   VERSION
bot                     true    false                   xyz-bot 

I’m using helmfile v0.149

voron avatar

Did you tried to “output” $item.name w/o condition ?

Ivo avatar

I have no idea why but it seems to work now:

{{ range $index,$item := readDirEntries "./policies" }}
  {{- if and $item.IsDir (eq $item.Name $.Environment.Name) }}
  - name: policies-{{ $item.Name }}
    chart: ./policies/{{ $item.Name }}
  {{- end -}}
  {{- end -}}
Ivo avatar

Really weird, but happy that it works. Thanks for thinking with me on this, it did help to get a working solution

1
Ivo avatar

Seems a little stupid to iterate over all the directories but I couldn’t find a ‘direct’ check. Is there any way to avoid the dot being evaluated as a fs.DirEntry and use the environment name instead?

Ivo avatar

Putting it in a variable outside the loop {{ $env := .Environment.Name }} seems to trigger the same error.

2023-04-11

Alexander Taran avatar
Alexander Taran

Hi gents Is it possible to somehow use template values un Chart.yaml? I have a library chart and based on environment I need to specify registry for the lib chart. Chart.yaml example that I want to achieve but this doesn’t work:

apiVersion: v2
name: datasources
version: 0.1.0
description: Chart to deploy 
dependencies:
  - name: common
    version: 1.2.0
    repository: "{{ .StateValues.registry.helm }}"
Sajja Sudhakara Rao avatar
Sajja Sudhakara Rao

Isn’t it {{ .Values.registry.helm }}

Alexander Taran avatar
Alexander Taran

It’s almost the same things afaik. Problem not in how to use that variable. I did’t find is it possible to use helmfile variables in Chart.yaml

Sajja Sudhakara Rao avatar
Sajja Sudhakara Rao

May be not same. ‘Values’ this could be the keyword in helm terminology. Can u try that and see if it work. Pls ignore if you have tried already

bradym avatar

Pretty sure you can’t template Chart.yaml

Alexander Taran avatar
Alexander Taran

@bradym Is there a workaround? I saw documentation provides some but they are not applicable to my case

Alexander Taran avatar
Alexander Taran

@Sajja Sudhakara Rao you are right, I want to use values from helmfile not from helm therefore I used StateValues. But in any case I tried this option too) Thank you)

bradym avatar

I’ve never needed to do this, but I’d probably write a script to use vals (https://github.com/helmfile/vals) to set that value before running helmfile on the results. vals is used as a lib in helmfile so if you’re using ref or secretref to get secrets from something like aws ssm or vault it works the same.

helmfile/vals

Helm-like configuration values loader with support for various sources

Alexander Taran avatar
Alexander Taran

looks interesting,going to check thanks you

2023-04-12

Brandon Nason avatar
Brandon Nason

I’ve just stumbled upon helmfile and it looks like it can really solve some of my pain points with helm and my workarounds (custom shell scripts). The main thing I need is the ability to add new manifests (with env vars). It looks like this is done by using a dependency incubator/raw which expects the manifests to be inline. so 1) Is there a way to put those manifests into their own files with requiredEnv support and 2) it appears incubator/raw is deprecated. Should I be using something different?

Brandon Nason avatar
Brandon Nason

It looks like helm-x support for using a dir of manifests was added, though I’m not sure how to get it to work. Here is my current helmfile.yaml but I’m getting an error on the dependency:

Error: dependency "manifests" has an invalid version/constraint format: improper constraint: ]

repositories:
- name: vsphere-tmm
  url: <https://vsphere-tmm.github.io/helm-charts>

releases:
- chart: vsphere-tmm/vsphere-csi
  version: 3.0.2
  name: vsphere-csi
  namespace: vsphere-csi-system
  createNamespace: true
  values:
    - helm/values.yaml
  dependencies:
    - chart: ./templates/manifests/
Brandon Nason avatar
Brandon Nason

Though it looks like helm-x might be abandoned…. disappointing

Brandon Nason avatar
Brandon Nason

Yea I’m very confused. Apparently chartify handles the releases[].dependencies and it is supposed to be able to turn a dir of manifests into a chart, chartify is a Go library that is primarily used by helmfile to let it convert Kuberntes resource YAMLs or kustomize into a helm chart, and apply various modifications to the resulting chart. However @mumoshu explicitly states that it’s integration into helmfile doesn’t work that way. https://github.com/helmfile/helmfile/issues/472#issuecomment-1312620664 though maybe I’m mixing up what helm-x is theoretically intended to handle.

Brandon Nason avatar
Brandon Nason

And then if I have to create a chart for my local manifests already, I’m not sure what the point of the helmfile here is hmm

mumoshu avatar
mumoshu

helm-x is now chartify and chartify can treat raw manifests dir as a chart. however, it does not support manifests-as-chart in adhoc dependencies yet!

mumoshu avatar
mumoshu

re incubator/raw, just keep using it or fork it if necessary. we dont host our own raw chart due to limited bandwidth so it’s unfortunately your responsibility…

Brandon Nason avatar
Brandon Nason

Ahh ok, thanks for the information. So for the moment, if I want to use manifest files, I have to create a local chart and set that as a dependency. If instead I put the manifests inline, I don’t have to create a chart. Correct? Will either method still allow usage of requiredEnv ?

mumoshu avatar
mumoshu

requiredEnv is available within helmfile.yaml and values.yaml templates so if you are trying to write templates within a non-chart local directory and wanting chartify to treat it as a chart, that’s impossible

Brandon Nason avatar
Brandon Nason

Right, I would have to create a local chart, and then pass it a values.yaml that has the requiredEnv values?

mumoshu avatar
mumoshu

do you really need adhoc dependencies? i think you can just point releases[].chart to a local directory containing raw manifests.

mumoshu avatar
mumoshu

yeah you’d need to do so if you need to dynamically generate release values from envvars.

Brandon Nason avatar
Brandon Nason

Well I want to bundle my changes with the existing chart that I’m trying to extend so they are upgraded together. Using 2 releases, one being the original chart and the other being my local manifests would treat them as separate things right?

Brandon Nason avatar
Brandon Nason

Also, just a dir of manifests can be used in releases[] just not releases[].dependencies? correct?

mumoshu avatar
mumoshu


Using 2 releases, one being the original chart and the other being my local manifests would treat them as separate things right?
Yes

mumoshu avatar
mumoshu


ust a dir of manifests can be used in releases[] just not releases[].dependencies
Correct

mumoshu avatar
mumoshu

Then the only way possible today would be to add incubator/raw as an adhoc dependency and write some values to add your resources

releases:
- name: foo
  chart: whatever/main/chart
  values:
  - bar:
      resources:
      - kind: ConfigMap
        apiVersion: v1
        data:
          foo: bar
  dependencies:
  - name: bar
    chart: incubator/raw

2023-04-13

2023-04-17

voron avatar

I’m curious is there an option to specify helmfile environment (helmfile -e ) via OS environment variable ?

1
yxxhero avatar
yxxhero

only options. if you like. please post a feature request.

voron avatar

It seems that HELMFILE_ENVIRONMENT does the trick :

1
yxxhero avatar
yxxhero

yxxhero avatar
yxxhero

I forgot it.

1
voron avatar

It was there for a long time, but it’s undocumented

#1425 HELMFILE_ENVIRONMENT variable

A simple change to allow the ‘environment name’ to be set by an environment variable. Precedence have command line option.

yxxhero avatar
yxxhero

PR is welcome. @voron

yxxhero avatar
yxxhero

voron avatar

Yea, I was looking what files I need to patch and was not able to find any specific place. It seems there is no ready sections for CLI args or HELMFILE_* env vars

voron avatar

Oh I see CLI reference

yxxhero avatar
yxxhero

you can add a new section for ENVs.

yxxhero avatar
yxxhero

@voron

voron avatar

yep, will try to do it

yxxhero avatar
yxxhero

Thanks so much. @voron I will review it as sone as I can.

1
yxxhero avatar
yxxhero

yxxhero avatar
yxxhero

Please fix dco issue.

1
yxxhero avatar
yxxhero

@voron

1
voron avatar

It’s fixed

yxxhero avatar
yxxhero

Awesome

yxxhero avatar
yxxhero

done

1
Nathanael avatar
Nathanael

I’m try to use HELMFILE_V1MODE=true because we want to be prepared but i think our concept does break with v1 :thinking_face:

We do nested helmfiles (terraform-module-like) but we also want to ‘gotemplate the sub-helmfile itself. We used helmfile.yaml for the sub-helmfile and with the HELMFILE_V1MODE=true i’m forced to change the filename to helmfile.yaml.gotmpl if i do that, the main execution of the parrent helmfile returns this error:

err: no releases found that matches specified selector() and environment(stagename), in any helmfile

(no i do not intend to use selectors so no labels, no selectors are used) why is that? and is our entire concept borken with v1 ?

#594 feat: Helmfile V1 mode

We add a new “V1 mode” to Helmfile so that you can seemlessly upgrade Helmfile from the current v0.x to the upcoming v1.0.

The idea is that we build both v0 and v1 binaries from the same tagged commit within the main branch, with different defaults for the “V1 mode”- the V1 mode is disabled by default for v0.x binaries, while it is enabled by default for v1.x binaries.

The V1 mode can be overrode at runtime via envvar. That is, even after upgrading the binary to v1, you will not see any backward-incompatible changes while you explicitly set an envvar, HELMFILE_V1MODE=true, at runtime.

Signed-off-by: Yusuke Kuoka [email protected]

1

2023-04-18

2023-04-19

Dominic Cardellino avatar
Dominic Cardellino

I got a question and maybe it is already answered a thousand times I really love to use helmfile, but how do I handle the creation of Kubernetes Manifests(like ConfigMaps, Secrets etc.) outside of a Helm Chart. Currently I use terraform to deploy kubernetes resources (kubernetes provider) and helm releases (helm provider), but it just feels kind of wrong at sometime to use terraform for this

voron avatar

we usually use raw chart for that and pass the whole manifest as helm values. F.e. https://artifacthub.io/packages/helm/itscontained/raw

raw 0.2.5 · itscontained/itscontainedattachment image

A place for all the Kubernetes resources which don’t already have a home

Dominic Cardellino avatar
Dominic Cardellino

This looks good awesome

2023-04-24

Aljoscha Weber avatar
Aljoscha Weber

Hey together, hopefully a small question: how does one apply a helmfile which includes sub-helmfiles? My current unexpected result is “no releases found that match my selector() and environment(dev) I’m trying to setup a layered helmfile and staying as DRY as i can - my use case is for example multiple mongdb-databases and they are 90% the same with only minor diffs in the values (persistence size for example):

070-my-service-mongodb.yaml.gotmpl:

bases:
  - 000-environments.yaml.gotmpl
  - 000-repositories.yaml

---

helmfiles:
  - path: _mongodb.helmfile.yaml.gotmpl
    values:
    - {{ toYaml .Values | nindent 4 }}
    - releaseName: my-service-mongodb
      releaseNamespace: {{ .Values.myMainNamespace }}

000-environments.yaml.gotmpl:

environments:
  default:
    values:
      - "../environments/dev.values.yaml"
  dev:
    values:
      - "../environments/dev.values.yaml"

---

helmDefaults:
  kubeContext: {{ .Values.kubeContext }}
  verify: false
  wait: true
  timeout: 1800
  tls: false

_mongodb.helmfile.yaml.gotmpl:

---
releases:
- name: {{ .Values.releaseName }}
  installed: true
  namespace: {{ .Values.releaseNamespace }}
  labels:
    release: "{{`{{ .Release.Name }}`}}"
    namespace: "{{`{{ .Release.Namespace }}`}}"
  chart: bitnami/mongodb
  version: {{ .Values.bitnamiMongoDbChartVersion }}
  values:
    - "../values/infrastructure/mongodb/mongodb.values.yaml.gotmpl"
  wait: true

- name: {{ .Values.releaseName }}-backup
  namespace: {{ .Values.releaseNamespace }}
  labels:
    release: "{{`{{ .Release.Name }}`}}"
    namespace: "{{`{{ .Release.Namespace }}`}}"
    type: backup
  chart: myCharts/jobs
  version: {{ .Values.jobsChartVersion }}
  values:
    - "../values/infrastructure/mongodb/mongodb-backup.values.yaml.gotmpl"
  wait: true

Output of HELMFILE_V1MODE=true helmfile --debug -i -f ~/IdeaProjects/my-helmfile/helmfile.d/070-my-service-mongodb.yaml.gotmpl -e dev apply

...
A LOT OF ENV + ENV_DEBUG
...
rendering result of "_mongodb.helmfile.yaml.gotmpl.part.0":
 0: ---
 1: releases:
 2: - name: my-service-mongodb
 3:   installed: true
 4:   namespace: my-service-dev
 5:   labels:
 6:     release: "{{ .Release.Name }}"
 7:     namespace: "{{ .Release.Namespace }}"
 8:   chart: bitnami/mongodb
 9:   version: 13.9.4
10:   values:
11:     - "../values/infrastructure/mongodb/mongodb.values.yaml.gotmpl"
12:   wait: true
13: 
14: - name: my-service-mongodb-backup
15:   namespace: my-service-dev
16:   labels:
17:     release: "{{ .Release.Name }}"
18:     namespace: "{{ .Release.Namespace }}"
19:     type: backup
20:   chart: myCharts/jobs
21:   version: 13.9.4
22:   values:
23:     - "../values/infrastructure/mongodb/mongodb-backup.values.yaml.gotmpl"
24:   wait: true
25: 

changing working directory back to "/Users/PRIVATE/IdeaProjects/my-helmfile/helmfile.d"
helm:XBjnS> v3.11.2+g912ebc1
helm:XBjnS> 
Adding repo bitnami <https://charts.bitnami.com/bitnami>
exec: helm --kube-context my-aks repo add bitnami <https://charts.bitnami.com/bitnami> --force-update
helm:MRUSy> "bitnami" has been added to your repositories
helm:MRUSy> 
"bitnami" has been added to your repositories

0 release(s) found in 070-my-service-mongodb.yaml.gotmpl:

changing working directory back to "/Users/PRIVATE/IdeaProjects/my-helmfile/helmfile.d"
err: no releases found that matches specified selector() and environment(dev), in any helmfile

In the debug i can find the 2 releases and they look as i would expect it, but then they are not found for applying?

Aljoscha Weber avatar
Aljoscha Weber

i think i found the cause of the error: my sub-helmfile does not contain environments, as i am trying to pass the values in the main helmfile, i now added:

bases:
- 000-environments.yaml.gotmpl
---

and now it looks like it can apply, which looks related to https://github.com/roboll/helmfile/issues/704

#704 Unable to matches specified selector() and environment(master), in any helmfile when using Helmfiles

I’m trying to make my helmfiles DRY

helmfile.yaml

helmfiles:
- apps/99_monitor.yaml

apps/99_monitor.yaml

bases:
- ../common/environments.yaml
- ../common/repositories/kubernetes.yaml
- ../common/helmdefaults.yaml

{{ readFile "../common/templates.yaml" }}

releases:
  - name: gitlab-{{ .Environment.Name }}-branch-fluent-bit
    chart: stable/fluent-bit
    version: ~1.8.0
    values:
      - "../environments/{{ `{{ .Environment.Name }}` }}/gitlab-{{ `{{ .Environment.Name }}` }}-branch-fluent-bit.yaml"
    <<: *default

If I lint charts, using apps/99_monitor.yaml I’ve no errors:

$ helmfile -e master --log-level debug -f apps/99_monitor.yaml lint                                                      
processing file "99_monitor.yaml" in directory "apps"
changing working directory to "/home/jjmartres/Desktop/deploy/apps"
first-pass rendering starting for "99_monitor.yaml.part.0": inherited=&{master map[] map[]}, overrode=<nil>
first-pass uses: &{master map[] map[]}
first-pass produced: &{master map[] map[]}
first-pass rendering result of "99_monitor.yaml.part.0": {master map[] map[]}
vals:
map[]
defaultVals:[]
second-pass rendering result of "99_monitor.yaml.part.0":
 0: environments:
 1:   master:
 2:   review:
 3: 

merged environment: &{master map[] map[]}
first-pass rendering starting for "99_monitor.yaml.part.1": inherited=&{master map[] map[]}, overrode=<nil>
first-pass uses: &{master map[] map[]}
first-pass produced: &{master map[] map[]}
first-pass rendering result of "99_monitor.yaml.part.1": {master map[] map[]}
vals:
map[]
defaultVals:[]
second-pass rendering result of "99_monitor.yaml.part.1":
 0: repositories:
 1:   - name: kubernetes-charts
 2:     url: <https://kubernetes-charts.storage.googleapis.com/>
 3: 

merged environment: &{master map[] map[]}
first-pass rendering starting for "99_monitor.yaml.part.2": inherited=&{master map[] map[]}, overrode=<nil>
first-pass uses: &{master map[] map[]}
first-pass produced: &{master map[] map[]}
first-pass rendering result of "99_monitor.yaml.part.2": {master map[] map[]}
vals:
map[]
defaultVals:[]
second-pass rendering result of "99_monitor.yaml.part.2":
 0: helmDefaults:
 1: #  args:
 2: #    - "--debug"
 3: #   Differents contexts: <https://www.reddit.com/r/kubernetes/comments/am5mcq/helmfile_how_to_deal_with_different_versions_in/>
 4: 

merged environment: &{master map[] map[]}
first-pass rendering starting for "99_monitor.yaml.part.3": inherited=&{master map[] map[]}, overrode=<nil>
first-pass uses: &{master map[] map[]}
could not deduce `environment:` block, configuring only .Environment.Name. error: failed to read 99_monitor.yaml.part.3: reading document at index 1: yaml: unknown anchor 'default' referenced
error in first-pass rendering: result of "99_monitor.yaml.part.3":
 0: 
 1: 
 2: releases:
 3:   - name: gitlab-master-branch-fluent-bit
 4:     chart: stable/fluent-bit
 5:     version: ~1.8.0
 6:     values:
 7:       - "../environments/{{ .Environment.Name }}/gitlab-{{ .Environment.Name }}-branch-fluent-bit.yaml"
 8:     <<: *default
 9: 

first-pass produced: &{master map[] map[]}
first-pass rendering result of "99_monitor.yaml.part.3": {master map[] map[]}
second-pass rendering result of "99_monitor.yaml.part.3":
 0: templates:
 1:   default: &default
 2:     namespace: "gitlab-{{ `{{ .Environment.Name }}` }}-branch"
 3:     atomic: true
 4:     missingFileHandler: Warn
 5:     recreatePods: true
 6:     wait: true
 7: 
 8: 
 9: releases:
10:   - name: gitlab-master-branch-fluent-bit
11:     chart: stable/fluent-bit
12:     version: ~1.8.0
13:     values:
14:       - "../environments/{{ .Environment.Name }}/gitlab-{{ .Environment.Name }}-branch-fluent-bit.yaml"
15:     <<: *default
16: 

merged environment: &{master map[] map[]}
Adding repo kubernetes-charts <https://kubernetes-charts.storage.googleapis.com/>
exec: helm repo add kubernetes-charts <https://kubernetes-charts.storage.googleapis.com/>
exec: helm repo add kubernetes-charts <https://kubernetes-charts.storage.googleapis.com/>: "kubernetes-charts" has been added to your repositories

"kubernetes-charts" has been added to your repositories

Updating repo
exec: helm repo update
exec: helm repo update: Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "anasen" chart repository
...Successfully got an update from the "gitlab" chart repository
...Successfully got an update from the "kubernetes-charts" chart repository
...Successfully got an update from the "stable" chart repository
...Successfully got an update from the "bitnami" chart repository
Update Complete.

Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "anasen" chart repository
...Successfully got an update from the "gitlab" chart repository
...Successfully got an update from the "kubernetes-charts" chart repository
...Successfully got an update from the "stable" chart repository
...Successfully got an update from the "bitnami" chart repository
Update Complete.

worker 1/1 started
Fetching stable/fluent-bit
exec: helm fetch stable/fluent-bit --version ~1.8.0 --untar --untardir /tmp/085914238/gitlab-master-branch-fluent-bit/~1.8.0/stable/fluent-bit
exec: helm fetch stable/fluent-bit --version ~1.8.0 --untar --untardir /tmp/085914238/gitlab-master-branch-fluent-bit/~1.8.0/stable/fluent-bit: 
worker 1/1 finished
successfully generated the value file at ../environments/master/gitlab-master-branch-fluent-bit.yaml. produced:
backend:
  type: es
  es:
    host: elasticsearch-client.namespace.svc.cluster.local
    port: 9200
    index: master_branch
    logstash_prefix: master_branch

Linting /tmp/085914238/gitlab-master-branch-fluent-bit/~1.8.0/stable/fluent-bit/fluent-bit
exec: helm lint /tmp/085914238/gitlab-master-branch-fluent-bit/~1.8.0/stable/fluent-bit/fluent-bit --namespace gitlab-{{ .Environment.Name }}-branch --values /tmp/values179823557
exec: helm lint /tmp/085914238/gitlab-master-branch-fluent-bit/~1.8.0/stable/fluent-bit/fluent-bit --namespace gitlab-{{ .Environment.Name }}-branch --values /tmp/values179823557: ==> Linting /tmp/085914238/gitlab-master-branch-fluent-bit/~1.8.0/stable/fluent-bit/fluent-bit
Lint OK

1 chart(s) linted, no failures

==> Linting /tmp/085914238/gitlab-master-branch-fluent-bit/~1.8.0/stable/fluent-bit/fluent-bit
Lint OK

1 chart(s) linted, no failures

But If I lint charts using helmfile.yaml I got the following error:

$ helmfile -e master --log-level debug lint       
processing file "helmfile.yaml" in directory "."
first-pass rendering starting for "helmfile.yaml.part.0": inherited=&{master map[] map[]}, overrode=<nil>
first-pass uses: &{master map[] map[]}
first-pass produced: &{master map[] map[]}
first-pass rendering result of "helmfile.yaml.part.0": {master map[] map[]}
vals:
map[]
defaultVals:[]
second-pass rendering result of "helmfile.yaml.part.0":
 0: helmfiles:
 1: - ./apps/99_monitor.yaml
 2: 

err: no releases found that matches specified selector() and environment(master), in any helmfile

What’s going wrong ?

Aljoscha Weber avatar
Aljoscha Weber

update: by adding the environments to the sub-helmfile i got now the problem that list-elements are duplicated inside which is wrong, i think that’s the case because the environments will also be merged and then the result will be sth. like 2 times the result

Aljoscha Weber avatar
Aljoscha Weber

second update: HELMFILE_V1MODE=true changes the behaviour and i get duplicated list results

2023-04-27

2023-04-28

Dominic Cardellino avatar
Dominic Cardellino

Hey together,

Did anyone experience this message with helmfile?

failed to render [values.yaml.gotmpl], because of template: stringTemplate:113: function "toUpper" not defined

Trying to render sth like this:

templateFiles:
  {{ define "slack.title" -}}
    [{{ .Status | toUpper -}}
    {{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{- end -}}
    ] {{ .CommonLabels.alertname }}
  {{- end }}

  {{ define "slack.text" -}}

It is my prometheus alertmanager config which uses this functions

Andrew Nazarov avatar
Andrew Nazarov

The corresponding sprig function is upper http://masterminds.github.io/sprig/strings.html

String Functions

Useful template functions for Go templates.

Dominic Cardellino avatar
Dominic Cardellino

@Andrew Nazarov Now I get:

failed to render [values.yaml.gotmpl], because of template: stringTemplate:113:14: executing "slack.title" at <.Status>: can't evaluate field Status in type state.releaseTemplateData

Dominic Cardellino avatar
Dominic Cardellino
#700 Templating complex values.yaml files

Consider the following values.yaml file. This is an excerpt from the default values file for the prometheus helm chart:

## ConfigMap override where fullname is {{.Release.Name}}-{{.Values.server.configMapOverrideName}}
## Defining configMapOverrideName will cause templates/server-configmap.yaml
## to NOT generate a ConfigMap resource
##
configMapOverrideName: ""

When we’re attempting to use helmfile to template into this values.yaml.gotpl file, we are seeing errors. Obviously it is picking up on {{ and seeing it as a template. We can accept this for comments since they can simply be deleted, however the same thing is happening for nested values that are not in comments.

## alertmanager ConfigMap entries
##
alertmanagerFiles:
  alertmanager.yml:
    global:
      slack_api_url: '<https://slack.com>'

    receivers:
    - name: default-receiver
      pagerduty_configs:
        - service_key: key
      slack_configs:
      - channel: '{{ .CommonAnnotations.channel }}'
        send_resolved: true
        title: '{{ template "slack.default.title" . }}'
        title_link: '{{ template "slack.default.titlelink" . }}'
        pretext: '{{ .CommonAnnotations.summary }}'
        text: |-
          {{ range .Alerts }}
             *Alert:* {{ .Annotations.summary }} - `{{ .Labels.severity }}`
            *Description:* {{ .Annotations.description }}
            *Details:*
            {{ range .Labels.SortedPairs }} • *{{ .Name }}:* `{{ .Value }}`
            {{ end }}
          {{ end }}

To be completely honest, I don’t really know what the answer to this question is. It is understandable that helmfile is detecting these interpolation tokens - however it introduces a lot of escaping and complexity. Given that prometheus is such a widely used chart, I felt it was worth raising to start a discussion.

Elisha Bello avatar
Elisha Bello

hey guys I’m trying to achieve path base routing in an ALB created BY AWS Load Balancer Controller upon ingress object been initialise

apiVersion: [networking.k8s.io/v1](http://networking.k8s.io/v1) kind: Ingress metadata: name: {{ .Chart.Name }}-ingress-rules annotations: [alb.ingress.kubernetes.io/scheme](http://alb.ingress.kubernetes.io/scheme): internet-facing [alb.ingress.kubernetes.io/target-type](http://alb.ingress.kubernetes.io/target-type): ip [alb.ingress.kubernetes.io/group.name](http://alb.ingress.kubernetes.io/group.name): {{ .Values.ingress.lbGroup }} [alb.ingress.kubernetes.io/load-balancer-name](http://alb.ingress.kubernetes.io/load-balancer-name): {{ .Values.ingress.lbGroup }} [alb.ingress.kubernetes.io/listen-ports](http://alb.ingress.kubernetes.io/listen-ports): '[{"HTTP":80},{"HTTPS":443}]' [alb.ingress.kubernetes.io/ssl-redirect](http://alb.ingress.kubernetes.io/ssl-redirect): "443" [alb.ingress.kubernetes.io/security-groups](http://alb.ingress.kubernetes.io/security-groups): {{ .Values.ingress.securityGroup }} [external-dns.alpha.kubernetes.io/hostname](http://external-dns.alpha.kubernetes.io/hostname): {{ .Values.ingress.host }} [external-dns.alpha.kubernetes.io/alias](http://external-dns.alpha.kubernetes.io/alias): "true" spec: ingressClassName: alb rules: - host: {{ .Values.ingress.host }} http: paths: - path: {{ .Values.ingress.intercomPath }} pathType: Prefix backend: service: name: {{ .Values.ingress.intercomServiceName }} port: number: {{ .Values.ingress.intercomServicePort }}

      `- path: {{ .Values.ingress.engagePath }}`
        `pathType: Prefix`
        `backend:`
          `service:`
            `name: {{ .Values.ingress.engageServiceName }}`
            `port:`
              `number: {{ .Values.ingress.engageServicePort }}`

      `- path: {{ .Values.ingress.usersPath }}`
        `pathType: Prefix`
        `backend:`
          `service:`
            `name: {{ .Values.ingress.usersServiceName }}`
            `port:`
              `number: {{ .Values.ingress.usersServicePort }}`

      `- path: {{ .Values.ingress.enrichPath }}`
        `pathType: Prefix`
        `backend:`
          `service:`
            `name: {{ .Values.ingress.enrichServiceName }}`
            `port:`
              `number: {{ .Values.ingress.enrichServicePort }}`

For some reason it seems not to work

yxxhero avatar
yxxhero

@Elisha Bello maybe you wanna ask a question about helm?

1
    keyboard_arrow_up