Add ability to specify tiller namespace

[rmartinez3]

I want to be able to use helmfile to talk to different instances of tillers in different namespace. I would like to add a global flag --tiller-namespace , to specify the namespace where tiller is located. Also if possible to have a tillerNamespace section in helmfile. That way can specify either via flag or helmfile what tiller to talk .

[mumoshu]

@rmartinez3 Hi! Thanks for the feature request 👍

Probably, adding --tiller-namespace to sync, diff, delete makes sense to me.
But FYI, I guess you can do that today with e.g. helmfile sync --args "--tiller-namespace=yourns".

I'd rather want to avoid enchancing helmfile.yml here.
The context is that, I basically like to include only declarative parts of helm releases in helmfile.yml.
--tiller-namespace seems like a part of operational knowledge - on developer's minikube you'd just want to omit tiller-namespace but in staging and prod clusters you'd want to specify the tiller-ns.

WDYT?

[rmartinez3]

Hello thanks for responding and thanks for the workaround.

Yes it makes sense to have it added to sync , diff and delete.

As for tiller-namespace being set via helmfile. The reason I would like to have it set. Its to minimize mistakes , currently we have our own maintained helmfile repo and will like to move back to main stream helmfile. We set the kube-context and tiller-namespace in helmfile.yaml, so that a install or upgrade via helmfile will be just referencing helmfile and values. That way the person using helmfile wouldn't have to worry about setting tiller-namespace flag. We currently have tiller instances deployed for different teams in each cluster and helmfile helps us distinguish what to deploy to. That with rbac, having teams with their own namespaces. Setting tiller-namespace via helmfile helps out.

I did see now that labels have been added via helmfile. So something i would look into as well.

[mumoshu]

@rmartinez3 Hi. Thank you so much for the detailed explanation!
I have not yet encountered advanced use-cases like yours myself, but I believe your points are valid and very important.

Looking back, we already have an operational knowledge of "which kube-context to be used by helmin ourhelmfile.yaml. It is named context:`, which you can see from the README of this project.

That being said, how about enhancing helmfile.yaml to add more operational context to helmfile?

Currently we have:

context: kubectl-context-name

How about enhancing it so that we can pack all the operational knowledge into it:

context:
  # What exists today
  kubeContext: default
  # Your requested feature
  tillerNamespace: yourns
  # Or even more flexible one...
  args: |
    {{ if (and (eq (env "HELMEFILE_ENV") "prod") (eq (env "HELMFILE_CMD") "sync") }}--wait{{ end }}

Alternative:

How about naming context to helmOptions or even helm so that we can be explicit about what resides under the key

helm:
  args:
  - --kube-context=default
  # Your requested feature
  - --tiller-namespace=yourns
{{ if (and (eq (env "HELMEFILE_ENV") "prod") (eq (env "HELMFILE_CMD") "sync") }}  - --wait{{ end }}

Pros are that this will become completely backward-compatible change with trivial code change. It will also address issues #64 and #84 cc/ @cmeury @sstarcher

[sstarcher]

I tend to lean toward typed values instead of a generic args as that allows us to validate syntax and structure, but of course is more work for us.

Either way with that information it likely makes sense to call the key something else.

[mumoshu]

I tend to lean toward typed values instead of a generic args as that allows us to validate syntax and structure, but of course is more work for us.

Good point. It would be definitely be a good thing for users!
How about start with args and accept contribution for dedicated keys?

[rmartinez3]

I like the idea of starting of with args as it will also address issues you mentioned. Accepting contributed dedicated keys will be great. Thanks again. I'll see if i get a chance to help out in this since I'm sure you guys are busy with other requests.

[rmartinez3]

Hello its been a while but have time again. I would like to add dedicated keys to the helmdefault section specifically tiller-namespace. Should I add kube-context as well? I was also considering adding arg merging on helmdefault.args and --args and given dedicated keys in helm default. In which --args will take precedence as well.

Also should I update docs to include helm default and functionality?

Thanks again

[sstarcher]

If adding arg merging --args should take precedence.

[rmartinez3]

Noted. Will work on this and make a pull request .

[rmartinez3]

Put up pull request #186 . Let me know if there are any changes/suggestions needed to merge this .

Thanks