#helmfile (2019-08)

Unforunately, no.

But we have a feature request to add a declarative way to manage ordering https://github.com/roboll/helmfile/issues/715 Pls feel free to +1 if you think it helps your use-case!

interesting idea! but not possible now.

it would worth a dedicated feature request. would you mind writing one?

maybe we can enhance the syntax being discussed/proposed in https://github.com/roboll/helmfile/issues/745#issuecomment-510737741 to also accept k8s secrets as sources.

in the meantime, use {{ exec "sh" (list "-c", "kubectl get secret .....") }} as a workaround

package scoped cache sounds like a good starting point! i do think that we’ll eventually need per-HelmState(or something nearby) cache but it isn’t needed as long as we don’t use helmfile as a go library

and thanks for the pr i’ll take a look soon

hm yeah. i’ll see if moving the cache up the stack makes more sense

Hey! There seems no way to scope deps to a single release without breaking helmfile.lock currently

Just curious, why you need to do so?

Pretty simple, I have an observe namespace with grafana, elasticsearch, prometheus etc etc etc. Maybe 20 or so charts. Upgrading everything at once is considerable change, particularly with complex ones like jenkins or prometheus

I think it worth a feature request to add helmfile an optional argument for which chart to receive updates

like helmfile deps one_of_your_chart_name_here

That’d be lovely

I can put that in tomorrow

thanks!

no, thank you!

You have an interesting use-case! Unfortunately Helmfile doesn’t have a feature that helps it today, but worth a feature request to helmfile and helm-x

one of featuers of helm-x is to add adhoc changes to the chart before installing it(like patches resources

so enhancing it to replace chart files (perhaps like helm x upgrade --install --replace-chart-file card.tmpl=yourown.card.tmpl?

and exposing the helm-x option to helmfile.yaml makes sense(perhaps with replaceFiles: {"card.tmpl": "yourown.card.tmpl }?

i’ve just released v0.81.0 12 minutes ago

oh. hah

(I believe a new release is cut pretty much for every merge to master)

…or it used to be

I see 0.81.0 is composed of multiple PRs

basically yes

i thought it would be better to cut a single version containing 3 prs from @tgroth this time

Yea, I think the main intent is just to keep releases flowing regularly so features (even if unintentionally broken and not fully baked) are readily available for testing.

definitely

there was a bit of a joke at work last week that @mumoshu might be dead since it had been a week since the last release

haha, thank god not! @mumoshu get some time off finally?

not really i was just busy handling reviews, questions and writing a few complementary go libraries for helmfile!

hopefully i can take some time off after the upcoming helm summit

@mumoshu are you going to attend Helm Summit, btw?

@Andrew Nazarov yes will you?

I would like to go, but don’t know yet. It contradicts my other plans and commitments. ~It’s too bad, there will be no talk about helmfile. At least I haven’t seen anything related to it in the schedule.~

Oh, shame on me, just double-checked and found your talk).

and i see an another helmfile user is giving a talk, too https://helmsummit2019.sched.com/event/S8tf/helm-for-anybody-combining-chatops-and-declarative-configurations-jonathan-striebel-scalable-minds-gmbh

At the same time with you))

@Shiva Gopal Hey! You need it included in the grafana.yaml:

releases:
- name: grafana
  namespace: grafana
  chart: stable/grafana
  values:
  - rbac:
      create: false
  - ./grafana_values.yaml

helmfiles:
- path: "../../modules/grafana/grafana.yaml"
  values:
  - "./grafana_values.yaml"

this isn’t valid as helmfiles[].values is for setting helmfile values, rather than release values.

@mumoshu - got it. if I want env specific values, is there a way to put in say sites/infra/dev/grafana_values.yaml ?

Read the docs and the above works! Thanks @mumoshu

Yeah that’s one of the good ways! You may also use {{.Environment.Name}}

one more thing… is there any way to the use the values file only if present? meaning if there is no additional config required, the users need not have the values file.

you can set the missing file handler to be warning or even debug

missingFileHandler parameter under releases. there’s a comment for it in the main README.md

Thanks @tgroth

Also is there a way to say use the directory from where the program was launched and use that as a parameter? It will save me from setting one ENV var

referencing PWD might do it

i haven’t tried it but it sounds like it might work

{{ requiredEnv "PLATFORM_ENV" }} syntax

no it’s a standard env var that already has your current directory

requiredEnv should get it (i think that’s a sprig or gotemplate function)

@tgroth - thanks it was user error Used PWD directly instead of “PWD”

@sung kang Hey! Could you try running it with debug logs like helmfile --log-level debug sync so that you can see how it is rendering your helmfile.yaml?

Anyways, I think {{ Environment.Values.externaldns.installed }} should be {{ .Environment.Values.externaldns.installed }}. It needs . before Environment

I can try to reproduce it if you could share the actual files you’re having the trouble

At least for now, I don’t see any issue in the example you’ve shared. It should work

Turns out the issue I was having had to do with boolean values

When I use the default function it doesn’t handle it correctly, switching to {{ get “” “”}} function addressed my issue

First, helmfile was born long before the terraform-helm-provider existed. Before that time, terraform wasn’t really an option.

Since then, the terraform-helm-provider came out. It was tempting at first, until we considered all that we would lose. In terraform 0.11, the templating was just not robust enough. It just handled simple replacement of variables. When working with values.yaml, it’s important to be able to deal with more complicated maps/lists, etc. Sometimes an entire section should be conditionally disabled.

Then terraform 0.12 came out. The gap closed. Now robust templating is possible in templates. It’s an appealing alternative, especially when everything else is in terraform. For example, many of our helm releases have AWS backing services. It would be nice to deploy the RDS database with terraform and then the helm chart immediately there after.

This is possible today.

However, doing so would give up the helm diff functionality. That’s a deal breaker in my book.

Basically, without helm diff, you have zero clue what’s going to happen.

There’s an option issue for this on terraform-helm-provider

https://github.com/terraform-providers/terraform-provider-helm/issues/79

(someone even suggested making it work more like helmfile! Props to @ausov.)

The issue has been open for over 1 year now with no movement. Not holding my breath.

Also, while I have the stage, want to call out a project @mumoshu is working on

https://github.com/mumoshu/helmfile-operator

Also, there’s https://github.com/Kubedex/terraform-helmfile

Not sure how I feel about that implementation though. We run terraform in a container, and this expects to run helmfile in a container, which causes a catch-22

@Shiva Gopal was this helpful? anything else you’re curious about…

@Erik Osterman (Cloud Posse) - this was super helpful. Let me digest the above and come back with any questions that I have.

@Daniel Johansson Hey! Unfortunately helmfile doesn’t have support for that today.

I can help debuggging tho
even though it looks to me that it should be set.

Would you mind sharing the snippet of your values.gotmpl or relevant files so that I can explain why it should/not work?