#helmfile (2021-03)

do you have a valid aws profile? i.e. does aws sts get-caller-identity return properly?

yes

terraform was recently updated to support sso, so it works with terraform, aws, kubectl. But not helmfile vals refs

@Marcus Ramberg i think the issue is with sops

https://github.com/mozilla/sops/issues?q=AWS+SSO

i know, it used to be a problem for us, and users had to start exporting variables before they could do it

in AWS SSO, if you go to `command line or programmatic access”. – it gives you a copy/paste of the access/secret and token

if you export those, you can use sops/helm-secret

@Justin Seiser I think you’re right. we’re using vals (ref+ urls) and not sops, but probably same workaround.

Just thinking aloud but maybe

$ helm upgrade --install ....

could solve this.

half serious / half joke

Have you considered postsync hook?

https://github.com/roboll/helmfile/#hooks

Perhaps we’d better add postinstall hooks to helmfile?

@mumoshu Hmm, how to “connect/call” helm chart’s post-upgrade hook with hooks defined in helmfile?

The more I look into this, the more I think that helmfile shouldn’t bother solving this one time operation. I extracted job from helmfile template and manually applied it with kubectl.

Probably it might be a bug if it doesn’t fail in such case

Do you have any github issue related to it?

Found https://github.com/roboll/helmfile/issues/1728

Probably it might be a bug if it doesn’t fail in such case Actually it’s the opposite - I don’t want it to fail, because I know that the referenced object is not there yet:)

ah gotcha! that’s definitely not implemented. would be my next good exercise with https://github.com/variantdev/vals

One way to do that is using a template in your helmfile:

templates:
  default: &default
    values:
      - .env.{{ .Environment.Name }}.yaml

Then in your releases:

  - name: your_app
    version: 1.0
    <<: *default

I imagined that this could be the solution

Not claiming this is the best way, but it works for me.

You might also be able to do this in your helmfile:

values:
  - .env.{{ .Environment.Name }}.yaml

Which is what you originally suggested.

It may actually work, though. I’ve got a section like that where I’m setting individual values.

Never tried it myself, so not sure.

Well its not documented (or I’m not seeing it)

Yeah, there are some definite holes in the documentation

I think someone in here told me that you could do that with values

I can confirm it works. Used many times

you can add a

secrets:
  - secrets_file.yaml

https://github.com/roboll/helmfile/tree/v0.138.7

ot is ok secret was an example. it can be any type of resources.

maybe you can use the helmfiles: feature for nested states?

helmfiles:
  - path: ..

currently I solved it with a “custom” chart. that contains all yamls I need. but I will check that feature. thanks

You can create a “chart from a folder” and declare as a dependency. Used this approach in the past but had some issue with latest versions. There are some issue opened regarding how to create resources from scratch

@andrea.pavan how do you declare a chart as dependency?

  - name: prometheus-stack-addons
    namespace: monitoring
    labels:
      chart: prometheus-stack-addons
      repo: local
      component: monitoring-addons
      namespace: monitoring
    chart: ./prometheus-stack-addons
    version: "0.4.0"
    dependencies:
      - chart: incubator/raw
    wait: true
    installed: true
    atomic: true
    values:
      - "./prometheus-stack-addons-raw/raw_{{ .Environment.Name }}.yml"

this was an example I used to create brand new resources from simple yaml manifests The trick was declaring incubator/raw as a dependencies (attention that stable and incubator are now both deprecated). I used this in my previous job.

great, this dependencies should work with local charts as well, right?

I think so. Have a look at https://github.com/roboll/helmfile/issues/1547. I think it can help you to find the proper syntax

ok thanks!

BTW declaring it as:

dependencies:
 - chart: file://..path

throw a panic: runtime error: index out of range [1] with length 1 error.

If declared as

dependencies:
 - name: some_name
   repository: file://..path

as in the linked issue, it does not recognise those name and repository fields: field name not found in type state.Dependency

@gonzalez.mariano.gabr I have never tried file://..path so it might be not supported. Could you submit a github issue for that? (A tiny example for reproduction would be very much appreciated

@mumoshu it works by placing this dependencies directive in Charts.yaml (within the chart’s directory) instead of declaring it as part of the release. Not sure if that is the expected behaviour, but let me know if this is actually an issue or me just trying to do something not supported please

@gonzalez.mariano.gabr Thanks! I might say it’s a bug in helmfile. If that works in Chart.yaml, it should ideally work in releases.[].dependencies within helmfile.yaml, too

yeah. if I declare it it works, but as @mumoshu mentioned it would be awesome if it could work from helmfile,yaml too. should I create bug ticket about it ?

cool thank you for the clarification, will open an issue and let you know

I’d appreciate it if you could create one!

thanks

@mumoshu https://github.com/roboll/helmfile/issues/1762

@gonzalez.mariano.gabr Thanks! In this thread, I thought you’ve also mentioned

dependencies:
 - chart: file://..path

Is it supposed to work in Helm’s Chart.yaml? If so, I believe it should also be addressed in the issue

thank you guys.

@mumoshu well, actually I just tried chart: file://../path in Chart.yaml and it doesn’t work there either (it complains about no repository being declared..which makes sense), so maybe that is not something supported.

Gotcha! I’ll focus on repository thing then. Thanks for your confirmation

I opend an issue here: https://github.com/roboll/helmfile/issues/1739

@Nenad Strainovic Hey! I’ve just added another reply there

Yes its fu_ked

Oh well what was in [roboll.io](http://roboll.io)? I’ve never realized it was there

Sounds like there’s a conscious decision made against supporting template functions with this. https://github.com/variantdev/vals#non-goals Gonna just do base64 encoding in helm chart it self.

our lord and savior @Cameron Boulton pointed out this solution

{{ .Values.secrets.var123 | fetchSecretValue }}

Yeah the original design decision in vals was to not support templating but so many people asked for it in helmfile, and even a contributor submited a PR to add fetchSecretValue

so it’s there

hey! include isn’t supported in helmfile but you could intead if readFile and tpl