#helmfile (2019-09)

can you explain? I might need some kubectl rollout status ... && kubectl rollout undo .. equivalents in helmfile

Let me know if this makes sense

Lets say I have a helmfile deployment, with a replica of 2

then I do a second deployment updating that release with a missing docker image or maybe some other issue

when I tested the deploy it killed one of the two pods. Waited for it to go healthy - it never did, at which time helm/helmfile rolled back the release and it was back to running 2 healthy pods from the previous release

Does that help at all @rms1000watt?

Oh wait, so this happened automagically?
at which time helm/helmfile rolled back the release and it was back to running 2 healthy pods from the previous release

If so, then it’s all good

It did, but only with a replica of 2 or more. It wasn’t extensive testing though, so I’m not sure if there are edge cases I’m not aware of

I havent read fully but if you do want safe k8s deployment even with 1 replicas, I’d suggest configuring maxUnavailable and maxSurge in your deployment accordingly

For kubectl rollout status/undo I guess the only option today would be to use helmfile postsync hooks

But one of them results in error because of missing env vars

Hey! Would you mind sharing the actual error message you had seen?

Helmfile does intermediate rendering thing but I’m not sure if it matters in this case.

How does Jenkins parallel pipeline steps works? Does it share the workspace(=directory) across parallel steps - in this case multiple helmfile apply runs?

@TBeijen

Yes. It shares the workspace. I managed to work around it by copying helmfile and all related files to /tmp. Both helmfile processes run in separate containers so then it’s isolated.

Initially I was confused as on my local MacBook I found intermediate helmfile renders in tmp folder (as denoted by env var TMPDIR)

Yet in containers it didn’t seem to obey tmpdir and uses working dir?

I scanned codebase a bit and seemed to notice it using os.tempDir so that surprised me.

Yeah it should write all the temp files(=rendered values.yaml files passed to helm “-f” flags) somewhere under the tempdir

I can create a GitHub issue for it? It seems like a good option to be able to have it write temp files outside of the workspace.

That would be great!

Hmm, okay. I’m using the latest helmfile container. Might be how Jenkins does it’s magic that interferes with tmpdir behavior.

Will create a gh issue later (on mobile now)

Would you mind running helmfile with –log-level=debug, like helmfile --log-level=debug apply so that we can see where helmfile is actually writing files in the parallel containers

Okay! Thanks for your cooperation

Yes, already ran with debug. Need to curate some secrets but will include it.

Took some time (busy, busy): https://github.com/roboll/helmfile/issues/865

Hey! Unfortunately it isn’t currently supported. (Actually it worked before but there was really no concrete specification on how --args should work against any helmfile command that involves multiple helm commands.

So the direction is https://github.com/roboll/helmfile/issues/787

But I’m considering to make helmfile diff --args pass the args to helm diff only as an interim fix

@erik-stephens Does that make sense?

@mumoshu That’s perfect for me since that’s the only arg I care about right now. Thanks! Just an idea if ever revisit --args, maybe deprecate that if too hairy and provide a way via helmDefaults.COMMAND.args.

helmDefaults.COMMAND.args sounds great Thanks for your feedback!

FYI: --context N has been implemented today and is available since v0.84.0

@Steve Nolen Hey! Interesting question. Unfortunately there’s no way but I believe it worth a feature request.

awesome, I’ll write it up!

in the meantime, I think I’ve got a solution for myself by using

helmDefaults:
  kubeContext: {{ requiredEnv "KUBE_CONTEXT" | quote }}

when I force the env for setting context, I can then assume the env var is available in other locations and use it there. imperfect but it seems to work!

while i’m here @mumoshu, helmfile is a really, really great tool. Thank you for your efforts on it!

thanks for kind words it really encourages me!

should be possible. but you’re asking because it didn’t work?

@mumoshu not really, i dont know if its possible to find a key inside that

chart: "{{ `{{ .Release.Name }}`.chart }}"

the chart part is less critical, im just looking for a way how to include all values in 1 env file to have multiple services, and pass values of each service to a specific release

oh, that was easier than I thought. Thank you very much, Erik!

might you pls show what’s inside your helmfile?

@Asaduzzaman Pavel Hey! As @starets asked, would you mind sharing your helmfile.yam? Those errors seem to indicate that you have a bunch of syntax errors in your helmfile.yaml.

Generally speaking, you can use idioms like

releases:
- name: yourapp
  set:
  - name: key1
     file: path/to/file

and/or {{ readFile "path/to/file" | indent ... }}

@yuri Hey! So you wanna refer to the db release’s name from the app release, right? If so, unfortunately it isn’t possible.

How about just using a template variable though?

{{ $db_release := "mydb" }}

releases:
- name: {{ $db_release}}
  chart: charts/db
- name: app
  chart: charts/app
  values:
  - db:
      host: {{ $db_release }}:3306

@mumoshu thanks! not bad at all it can work for me

@yuri Thanks! Looks like it should just work.

I’m curious, but which version of helmfile are you running, and could you share logs from helmfile --log-level=debug -f yourhelmfile.yaml <CMD> so that you can see the intermediate result of rendered helmfile.yaml that helps debugging?

Ah

helmfile list works locally and is still useful to see the list of releases being installed BEFORE actually installing them.

But I’d say is IS confusing in contrast to helm list.

helmfile itself doesn’t store anything in cluster. all it depends are helm releases in cluster and local files

I’d like to improve the situation somehow.

Should we change helmfile to use helmfile list --local for the current behavior - list releases managed by helmfile, and use helmfile list for running helm list for each managed release to augment the result with info like REVISION UPDATED STATUS etc?

@Volodymyr Barna Would you agree with the change proposed above?

yes, that would be awesome!

wow! it when I do tillerless: true on the release itself it works! but not if I do it in helmDefaults, why? I have a dozen of releases I want to keep it DRY

btw releases and helmDefaults are separated by --- Because I need to use template values

so much magic is going on

but other values (like kubeContext) are propagated to each and every release. Can I somehow generate output template and see what goes where?

@Volodymyr Barna Hmmm, this sounds like a bug that is preventing helmDefaults.tillerless to releases somehow(it should!) I’ll take a look asap. Thx for reporting

Issue opened: https://github.com/roboll/helmfile/issues/875

maybe other values (like force, atomic) are not inhereted as well. I dunno how to check. I would be great if helmfile build would show everything that has been inhereted. And maybe add --with-default option which would also show the output file with all the possible parameters, including defaults

I wrote a reply, seems to be my issue, but stiil, I don’t know how to debug and any helm would be much appreciated

Once I had a feeling that some defaults were not taken into the consideration. But tillerless: true has been working for me like a charm. I don’t have --- between defaults and releases though. And I’m using pretty old helmfile version right now.

here in my case I have multiples helmfiles.yaml in order to use include flag, something like it:

ydf-stack on feature/cloudability» tree clusters                                                                                                                                                                                                                                                                                  [20:14:58]
clusters
├── americas
│   └── helmfile.yaml
├── apac
│   └── helmfile.yaml
├── commonHelmfile.yaml
├── emea
│   └── helmfile.yaml

I must to declare

helmDefaults:
  tillerNamespace: helm-revisions  #dedicated default key for tiller-namespace
  tillerless: true
  force: true

for each one of these files, would be great to declare in just the root files. americas/helmfile.yaml has an include to commonHelmfile.yaml.

helmfiles:
  - path: ../commonHelmfile.yaml

I don’t if we’re talking about the same problem, if not sorry

Nevermind. I needed an explicit repositories block

@aaronbatilo Thanks for sharing your finding!

That makes sense from the implementor’s perspective, but sounds a bit confusing from a users perspective

Any idea to improve it? Should helmfile fail if helmfile deps are run on a helmfile.yaml without the repositories block?

Omg it’s mumoshu. Big fan, big fan. I think that does should fail. It was unintuitive for me to see an exit code of 0 but nothing was happening

Thx for confirming!

Issue opened https://github.com/roboll/helmfile/issues/878

Perhaps another way would be to change Helmfile just emit some warning message to help you notice that you missed repositories block. Thoughts?

Pls feel free to reply here or in the issue

What kind of message do you imagine would be in the warning?

Oh, I see you left a message in the issue

something like

Unable to update chart dependencies due to that no `repositories` defined in your helmfile.yaml

Nothing to update. Did you miss `repositories` in your helmfile.yaml? See <https://github.com/roboll/helmfile/issues/878>

No repositories managed hence nothing to be updated by Helmfile. Did you miss repositories block in your helmfile.yaml?