#helmfile - January 2022

anyone able to explain what this means?

could not deduce `environment:` block, configuring only .Environment.Name. error: failed to read helmfile.yaml.part.0: reading document at index 1: yaml: unmarshal errors:
  line 3: cannot unmarshal !!map into []state.SubHelmfileSpec
error in first-pass rendering: result of "helmfile.yaml.part.0":

A couple of people have cut issues for this error notably one who said he fixed it but didn't post how he fixed it :sigh:

Would someone who knows helmfile really good be able to take a look at https://github.com/roboll/helmfile/issues/2036 and perhaps give me some pointers? The issue is attempting to point out poor documentation but I really do believe that the method I'm attempting to use for helmfile is sound and helmfile just needs better documentation methinks. -- TIA

Honestly the biggest problem with helmfile is the fact that Momushu seems to be the only maintainer. Dude is amazing, and has got to be burned out by all the work he's put into this project by now. I can't fathom how he couldn't be. Documentation the number two issue, which I'm sure comes from a lack of help maintaining the project.

If helmfile is going to continue and evolve I think it'll have to be by people who use it stepping up to help improve both of these situations.

I couldn't agree more! The question is whether contributors would be appreciated. Some maintainers really don't like others touching the code.

If I understood the ins and outs of helmfile better, I'd be willing to help with documentation. I did that with vault-secrets-webhook (bank-vaults) for banzaicloud.

at any rate, if anyone is able to give any kind of assistance on that question I have there...it would be greatly appreciated it

I might just have to wait for @mumoshu to take a look. He doesn't seem to have been around lately, though, so....maybe he's on a break.

Wish I could help, but my use of k8s and helmfiles seems to be so much simpler then everyone else around here.

That might sound wrong... I just mean that we only have two clusters and a handful of things that we deploy.

Very small shop compared to what I hear most people around here doing.

yeah...we have like...15 clusters and ~40 charts per....

our infra guys decided to use terraform to deploy helm charts using the terraform helm provider (which I think Mumoshu maintains/wrote actually) but imo, deploying software with terraform is a really really really bad idea blending infrastructure with software, which is poor practice. You really should keep those two things separate. The infra guys and we have been recognizing a great number of problems with this make up so I'm separating all of that out into helmfile. That's proving to be a chore because of what I've identified problematic given the size of our environment and what helmfile documentation speaks to.

This is a good #office-hours topic. Let's discuss next week

Unfortunately I can't make it to office hours due to a recurring work meeting at the same time, but I'll be interested to hear what comes out of the discussion.

I was wondering why SweetOps moved away from using Helmfile. I never understood the use cases, and not sure if I got a reply from the last time I asked this.

Terraform templating is clumsy (not sure if improved, e.g. indenting) where go-template with helmfile was richer, so felt helmfile was far easier to run multiple complex charts.

One advantage with Terraform was that you could use fetch data and secrets from the cloud for use as values in the helm charts without exposing it, where going between different tools, it could get complex.

Segue, I'm not sure if this exist, bu something could be done only in k8s land if there is cloud operator with CRD that could be used (but unfamiliar with this or if it is even viable). Google started something like this with their own CRD in k8s manifests, not sure how popular it is.

Hey @mumoshu!

We are looking for something like https://www.runatlantis.io/ (Terraform Github automation) but for Helmfile.

Are you aware of any tools that we can leverage to show diffs when running Helmfile in a CI env?

Helmfile quesiton/discussion; The releases[*].namespace will not populate the {{ .Namespace }} value used within releases[**].values[**].

But I can get this with -n mynamespace arg. I noticed when I do this, I don't see namespace injected with helm template, but I do see when finally deployed.

This issue comes up when I do a ClusterRoleBinding, and I was the subjects[0].namespace set appropriately.

Thoughts, is the expected behavior? desired behavior?

@mumoshu if you jump in here in a little while, I'd love to have a quick conversation about my last question in #2036 -- specifically, wondering how helmfile internally uses --- . It sounds like there's an order of operation helmfile adheres to but I'm not very clear on that. For instance, after changing/fixing the things suggested by you, it looks like bases loses the .Value read from environments in my helmfile approach. Now I might figure this out before you become available and if that happens, I'll let you know. For now, I'm workin on this. 🙂 TIA

I heard today that Jenkins X (jx3) is moving to adopt helmfile! That's pretty cool.

now if Jenkins just wasn't a piece of junk...that would be neat!

Hi, I'm trying to use helmfile to install dependencies, and then some resources for those dependencies (eg, ConfigMap for crossplane), so I have a templates directory alongside my helmfile.yaml. The dependency (crossplane) gets installed absolutely fine, but none of the templates (ConfigMap), are getting installed. Am i doing something wrong?

'nother helmfile question by yours truly...
so, I'm setting up my environment such that depending on settings in an environment.yaml, charts should be able to be enabled or disabled whereby when a chart is disabled, it's simply passed during helmfile processing and vice-versa. An example of what I'm doing is:
the env-toggle file:

# This file is only allowed to be a single dimension key value map
---
##################################
### globals                    ###
#
## use to set global cluster vars
cluster_domain_name: jimtest.dev.company
cluster_id: jimconn

enable_arm64_support: true
enable_aws_nlb_with_tls_termination_at_lb: false

##################################
### substrate                  ###
#
# use to enable substrate components
enable_argocd: true
enable_dex: true
enable_ambassador: true
enable_ingress_nginx: true
enable_opa_policy_manager: false

eventually, the ambassador release helmfile gets reached. I attempted using (along with a few other permutations):

{{ if .Values.enable_ambassador }}
releases:
  - name: ambassador
    namespace: {{ .Values.ambassador.namespace }}
    labels:
      app: ambassador
      tier: secrets-management
    values:
      - chart_repo: {{ .Values.ambassador.chart_repo }}
      - chart_version: {{ .Values.ambassador.chart_version }}
      - values.yaml.gotmpl
{{ else }}
releases:
  - {{ .Values | toYaml | nindent 4 }}
{{ end }}

which yields an error (along with the other permutations):

defaultVals:[]
second-pass rendering result of "helmfile.yaml.part.0":
 0: 
 1: releases:
 2:   - name: ambassador
 3:     namespace: ambassador
 4:     labels:
 5:       app: ambassador
 6:       tier: secrets-management
 7:     values:
 8:       - chart_repo: datawire/ambassador
 9:       - chart_version: 6.6.2
10:       - values.yaml.gotmpl
11: 
12: 

err: error during helmfile.yaml.part.0 parsing: encountered empty chart while reading release "ambassador" at index 0
changing working directory back to "repo/projects/helmfile-project/charts/10-cluster-mgmt"
changing working directory back to "repo/projects/helmfile-project/charts"
changing working directory back to "repo/projects/helmfile-project"
changing working directory back to "repo/projects/helmfile-project/environments"
changing working directory back to "repo/projects/helmfile-project/environments/devel"
in ./helmfile.yaml: in .helmfiles[0]: in ../helmfile.yaml: in .helmfiles[0]: in ../helmfile.yaml: in .helmfiles[0]: in charts/helmfile.yaml: in .helmfiles[1]: in 10-cluster-mgmt/helmfile.yaml: in .helmfiles[0]: in ambassador/helmfile.yaml: error during helmfile.yaml.part.0 parsing: encountered empty chart while reading release "ambassador" at index 0

I'm trying to do this in a way that is scalable. I mean, I could probably put an if-then within the helmfile.yaml one directory up from the release helmfile.yaml which is:

---
helmfiles:
- path: "*/helmfile.yaml"
  values:
  - {{ .Values | toYaml | nindent 4 }}

but if I use that method, this is not scalable in my setup as I would have to create a conditional for every single release I hold in this directory...vs using a wildcard in the path there. That doesn't scale....

Any suggestions?

With the most recent helmfile and helm-diff I started seeing errors during helmfile template for tfstate references like reading value for myproject-tf-state-dev/terraform/default.tfstate/output.filestore_instance_ip.value[0]: expected an object but got: array (["x.x.x.x"]). What component can cause this? helmfile, vals or tfstate-lookup? Can’t find changes that might affect this.

Does anyone uses helmfile to manage per-release secrets.yaml file with using secrets from it in values.yaml.gotmpl file? I have a problem that values from that secrets file are not available in Go templates, here is my issue about this https://github.com/roboll/helmfile/issues/2070
Maybe someone have found some workaround for this problem?

What does the valuesTemplate field mean in best practices documentation here https://github.com/roboll/helmfile/blob/master/docs/writing-helmfile.md#user-content-release-template--conventional-directory-structure ?

  valuesTemplate:
  - config/{{`{{ .Release.Name }}`}}/values.yaml
  secrets:
  - config/{{`{{ .Release.Name }}`}}/secrets.yaml

Can't find any documentation about it. Maybe it is used to attach values to already defined values in release?