Helmfile: Tags?

[xeor]

I really want to use 1 charts.yaml file for my project. But I want to be able to control the charts separate as well..

Would a tagging system be a good idea?

Example charts.yaml:

charts:
  - name: a1
    chart: ../charts/c1/
    tags:
      - tag1
  - name: a2
    chart: ../charts/c1/
    tags:
      - tag1
      - tag2
  - name: b1
    chart: ../charts/c1/
    tags:
      - tag3
  - name: c1
    chart: ../charts/c1/

Then helmfile could be used like:

# sync a1, a2
helmfile --tags tag1 sync

# sync a1, a2, b1
helmfile --tags tag1,tag3 sync

# sync all
helmfile sync

[mumoshu]

@xeor This is a great suggestion!

I'd also like to use it like, for example:

charts:
  - name: a1
    chart: ../charts/caching-proxy/
    tags:
      - frontend
  - name: a2
    chart: ../charts/web-server/
    tags:
      - frontend
  - name: b1
    chart: ../charts/api-server/
    tags:
      - backend
  - name: c1
    chart: ../charts/db-proxy/
    tags:
      - backend

and run helmfile --tags frontend sync and/or helmfile --tags backend sync.

[sstarcher]

I like the idea. It might make sense to follow the Kubernetes approach of

labels:
  key: value

Although the verbosity may not be necessary in this base case. It would also be nice if the name of the chart was a default tag or filter.

[xeor]

yea, that labels approach looks better.
Maybe there could be some meta-tags starting with _? Like _name..? :)

[mumoshu]

Thanks for suggestions 👍

Yeah, the labels approach sounds cool.
One thing I'm not sure though is - what if I just want to specify a key but omit its value.

Would my prev example turn into something like the below?

charts:
  - name: a1
    chart: ../charts/caching-proxy/
    labels:
      frontend:
  - name: a2
    chart: ../charts/web-server/
    labels:
      frontend:
  - name: b1
    chart: ../charts/api-server/
    labels:
      backend:
  - name: c1
    chart: ../charts/db-proxy/
    labels:
      backend:

Hmm, the verbosity does seem like a concern, as you pointed out :)

[mumoshu]

@xeor Thx! Would you mind sharing us what's your use-case of the meta tags?
It is just that I like to always start with an use-case :)

[mumoshu]

@sstarcher

It would also be nice if the name of the chart was a default tag or filter.

Interesting!
Would it make #30 unnecessary - in other words, its goal is achieved via default tags?

[sstarcher]

@xeor I like the idea of default meta tags like _name in that case it would work perfect with my suggestion of using key: value

_name: NAME would be a label by default and the same could be applied to chart, version etc

@mumoshu if we moved with meta tags it could deprecate #30

@mumoshu I would of thought it would of been the following, but apparently yours is also valid yaml.

charts:
  - name: a1
    chart: ../charts/caching-proxy/
    labels:
      frontend: ''
  - name: a2
    chart: ../charts/web-server/
    labels:
      frontend: ''
  - name: b1
    chart: ../charts/api-server/
    labels:
      backend: ''
  - name: c1
    chart: ../charts/db-proxy/
    labels:
      backend: ''

Instead I would recommend

charts:
  - name: a1
    chart: ../charts/caching-proxy/
    labels:
      tier: frontend
  - name: a2
    chart: ../charts/web-server/
    labels:
      tier: frontend
  - name: b1
    chart: ../charts/api-server/
    labels:
      tier: backend
  - name: c1
    chart: ../charts/db-proxy/
    labels:
      tier: backend

[xeor]

@mumoshu I don't know the usecases for meta-tags :) I just threw it in there, because I bet it might be useful for someone, or later.
The only meta-tag I can think about now is _name tho. Might be useful, but a more general -n a1would be better in that case...

Let me update the issue or create a new one if I come up with a good usecase. Unless @sstarcher got one :)

[sstarcher]

With metatags you get more than just _name. I could also install all charts for say _namespace: operations

Or update all charts nginx charts _chart: nginx This is useful if you have the same application deployed multiple times.

Of course instead of metatags we could just specifically implement each case, but if this PR was implemented it would be a nice way to have it all in one place.

[xeor]

Not the worst idea... :) Like it!

[sstarcher]

@xeor scathing praise ;)

[mumoshu]

If we had labels in helmfile.yaml, would the command be helmfile sync --labels tier=frontend?
Or should we name it after kubectl so that it will be helmfile sync --selector tier=frontend and helmfile sync -l tier=frontend?

[sstarcher]

I would lean toward using the same terminology as kubernetes as we are attempting exactly the same thing.

[mumoshu]

@sstarcher Thanks! Makes sense.
I'm going off today but if you have some time, would you mind submitting a PR for this?
Something without the default labels would be great for a starter!

[sstarcher]

@xeor this should be closed when we merge - https://github.com/roboll/helmfile/pull/30

[xeor]

Jep.. perfect :)

[mumoshu]

Closing as resolved via #30. Thank you very much for all your supports!