[Question] how does helmfile compares to helmsman?

[luisdavim]

Hi,

I would like to know, from your point of view, how you think helmsman and helmfile compare to each other.

Thanks.

[mumoshu]

@luisdavim Hey!

From my perspective, helmsman seems to have superior documentation and seems to have several features such as:

• generating plan files like terraform
• namespace and release protection
• toml support
• slack notifications

helmfile seems to be more handy when you want helm-secret support and more templating. helmfile is capable of templating helmfile.yaml and values.yaml.

In addition, #214 would allow us to leverage even more helm plugins. #227 will allow you to make each helmfile.yaml and values.yaml self-containted, that would help you organize a bunch of helm apps cleanly.

But I'm not an expert in helmsman. Please correct me or drop more information on helmsman, so that I can learn more to grow the helm ecosystem together ☺️ Thanks anyway!

[luisdavim]

Hi,

Thanks for answering. We've just started looking into a solution like this, so far, helmsman seems to be a better fit for us but helmfile seems to have better adoption and faster development pace so I guess we'll have to keep an eye on both of them for now.

Thanks

[mumoshu]

@luisdavim Thanks for the response!

Out of curiosity, what were your specific reasons to choose helmsman over other solutions?

I'm eager to learn about your use-case. Perhaps it may be a great source of inspiration to shape what we want for declarative management of helm releases in general!

[sstarcher]

This would be a great addition to helmfile

Idempotency: As long your desired state file does not change, you can execute Helmsman several times and get the same result.

[sstarcher]

The primary reason I use helmfile over something like helmsmen is the templating and structure as it's less verbose.

[luisdavim]

@mumoshu it was the closest to the needs we had for our pipelines. It manages tiller installation per ns, using tiller from kube-system can lead to privilege escalation, we wanted tiller per namespace controlled with rbac. It also supports promotion between namespaces and we use namespaces as stages (except prod) It supports private helm repos. And coming from terraform, having the plan feature makes it more familiar. Also, it can handle releases in the failed state.

[sstarcher]

ya, overall it looks like solve similar issues, but in very different manners.

[mumoshu]

Idempotency: As long your desired state file does not change, you can execute Helmsman several times and get the same result.

@sstarcher Would it be achievable via #205?

[mumoshu]

@luisdavim Thanks for sharing your insights ☺️

Let me comment one by one for perhaps better comparison of the tools, and to provide more contexts to users of the both tools.

It manages tiller installation per ns, using tiller from kube-system can lead to privilege escalation, we wanted tiller per namespace controlled with rbac.

That's a valid point!

I was personally considering to use helm-tiller, not to rely on server-side tiller at all. That is helm tiller run -- helmfile sync. It allows us to include the exact user name who ran helmfile, rather than the serviceaccount associated to a tiller, in k8s api audit logs.

Probably you want to create the serviceaccount passed to tillerServiceAccount before running helmsman? Also, it would be even nicer if you could declaratively managed the serviceaccount, too. An alternative would be to author your CI to run something like helm-tiller-rbac against the serviceaccount to add rbac policies and restart the tiller.

Not sure how helmfile would support that though!

Perhaps, if the plugin system (#214) realized, we could author a plugin to declaratively manage tiller-per-ns things, too? Or just add some documentation to explain how you could write bash to achieve that.

It also supports promotion between namespaces and we use namespaces as stages (except prod)

Interesting!

So, you're doing exactly what is described in the helmsman's docmentation about "move charts across namespaces"?

You may already know, but helmfile also accept which namespace the release should be installed, via namespace: setting per helm release in helmfile.yaml:

releases:
- name: myapp
  chart: ./mychart
  namespace: {{ env "HELMFILE_ENV" | default "default" }}-myapp

Although this may look similar to your helmsman config, helmfile as of today is unable to change the namespace of the release. That's due to that on helm upgrade $release $chart --namespace anotherns helm just ignores the new ns.

Perhaps we could enhance helmfile as suggested in #197, so that you could write:

releases:
- name: myapp
  chart: ./mychart
  namespace: production-myapp
  installed: {{ if eq (env "HELMFILE_ENV") "production" }}true{{ end }}
- name: myapp
  chart: ./mychart
  namespace: staging-myapp
  installed: {{ if eq (env "HELMFILE_ENV") "staging" }}true{{ end }}

It supports private helm repos.

helmfile does support private repos locked with username/password or tls client auth. Regarding AWS S3 as the repository backend, helmfile supports it when you have helm-s3 installed. See #220 for more context.

And coming from terraform, having the plan feature makes it more familiar.

I definitely agree on usefulness of terraform plan!

helmfile diff is intended to provide a comparable U/X of that. It shows diff between the current and the desired state like terraform plan, returning an exit code 0 when no diff, 2 when diff exists.

Would your use-case required a kind of terraform plan files? helmfile doesn't support it.

Also, it can handle releases in the failed state.

Interesting!

If you are talking about the workflow of "fix the problematic chart, and rerun helmsman, repeat, to converge the current state to the desired one", probably helmfile could support it via #205.

But in case helmsman is doing a fancier thing than just apply changes only when necessary, helmfile would be unable to support it.

[mumoshu]

Also, helmfile doesn't merge multiple DSFs into one like suggested in the helmsman issue https://github.com/Praqma/helmsman/issues/62. Instead, helmfile allows templating DSFs with golang text/template to achieve the same goal. See #96 for more context.

Moreover, helmfile -f path/to/directory sync syncs all the DSFs under the directory one by one, rather than merging them into one. This way, you can split your huge DSF into multiple, loosely coupled and isolated DSFs for better organization.

[luisdavim]

I like the idea of merging multiple files, it's like docker-compose and terraform tfvars work, my Idea there is to have layers that can be common and layers that are specific to each environment.

Helmsman doesn't have support for templating but it does support using environment variables directly on the DSF.

For the failed releases I think all it does is, it deletes the failed release and creates a new one and you can choose if you want to purge or not.

As I've said, for now we're going with helmsman but I do see that helmfile is evolving much faster, do I'll keep an eye on it.

[mumoshu]

@luisdavim Thanks for all the comments!

First of all, I do know you're going with helmsman. I just wanted to learn from your user-case so that I can shape how helmfile could help various users in the future! Of course please feel free to retry helmfile by any chance ☺️

I like the idea of merging multiple files, it's like docker-compose and terraform tfvars work

I think I have the same sentiment with you. Also, #59 #96 are very relevant requests from our users.

It would be just that, helmfile targets to manage a bunch of releases, while keeping DSFs small and concise. That's why I added the feature to split a DSF into multiple loosely coupled DSFs.

But obviously it doesn't reduce repetition among DSFs. The merge feature would indeed help reducing repetition required in order to write a lot of similar DSFs.

my Idea there is to have layers that can be common and layers that are specific to each environment.

I definitely agree with the benefit of having a common set of configs and layers.

If there's a chance helmfile supports it, helmfile.yaml can be enhanced to accept multiple yaml docs to be merged in the order of occurrence, rather than #96, to make the merge ordering concise.

{{ readFile "commons.yaml" }}
---
{{ readFile "layer.yaml" }}
---
# your custom helmfile.yaml content on top of the commons and the layer begins...

In your awesome PR to helmsman, I believe the merge ordering is specified via the order of command-line flags. helmfile will likely to keep helmfile.yaml self-contained https://github.com/roboll/helmfile/issues/59#issuecomment-416608106.

So, how the tool merges commons and layers will remain different between helmsman and helmfile.

it deletes the failed release and creates a new one and you can choose if you want to purge or not.

Awesome! I believe helmfile is unable to automatically delete the failed release on rerun. Could be a possible enhancement.

Thanks again for your comments!

[mumoshu]

Noted about how we should handle failed releases #256. Honestly I wasn't aware about the edge-cases explained in the relevant upstream issues. Good to know.

[mumoshu]

I've implemented a bunch of features recently so the only remaining features that were inspired by this discussion are #270 and #256.

270 has been already implemented but not yet merged, because it lacks concrete use-cases right now. An alternative to #270 that is already usable is #227. You can import and merge any yaml files into helmfile.yaml via golang templating.

Please comment on respective issues in case someone finds those features useful! Thanks.

[luisdavim]

that's awesome @mumoshu

[mumoshu]

Probably we can close this now? 😃

[cdaf]

Very late to the party, I find Helmsman has a better level of abstraction and suites CI/CD delivery well, however, Helmfile suites those who don't want the details obfuscated, and pairs well with a GitOps delivery approach.