Possible to set selector in parent helmfile?

[2ZZ]

I have a helmfile that pulls in another helmfile
cluster1-helmfile.yaml

---
context: cluster1
helmfiles:
 - apps-helmfile.yaml

Inside the second helmfile there are selectors
apps-helmfile.yaml

releases:
- name: app1
  chart: repo/app1
  version: '*'
  labels:
    enabled: app1
- name: app2
  chart: repo/app2
  version: '*'
  labels:
    enabled: app2

Currently I deploy it using

helmfile --selector enabled=app1 -f cluster-helmfile.yaml sync

Instead is it possible to set the enabled label in the parent helmfile? Similar to #168 (comment)

[mumoshu]

@2ZZ Yeah I see that there are use-cases like this!

What if we enhance helmfiles to accept more parameters per item, so that you could specify any supported options along with the name of sub-helmfile, like this:

helmfiles:
 - source: apps-helmfile.yaml
    selectors:
    - enabled=app1

[2ZZ]

that would be ideal for my use case 👍

[mumoshu]

The implementation for this would rely on the same mechanism for #168. The difference is that we add an another path to specify default selectors that is used while running sub-helmfiles.

[2ZZ]

Hi @mumoshu , I just discovered the context setting in the parent helmfile is not inherited in the included helmfiles, is that a bug or intentional?

[mumoshu]

@2ZZ That's intentional! I basically want each helmfile.yaml to be self-contained. That is, there should be no global state among parent and sub helmfiles.

[sgandon]

I would really appreciate this feature too cause we are compositing helmfiles but we sometimes do not want to install everything in the sub-helmfile.
I like the proposal with selector below the sub-helmfile path.
In fact there could be a section for each of the global options of the helmfile cli such as environment, kube-context, log-level, selector, namespace, interactive, quiet

[mumoshu]

@2ZZ That's intentional! I basically want each helmfile.yaml to be self-contained. That is, there should be no global state among parent and sub helmfiles.

@sgandon Can we start by reverting my previous comment above, and just pass the context(label selector from the command-line) down to all the sub-helmfiles?

The rationale is that I want everyone to be able to split helmfile.yaml without tears when it gets huge enough.

The label selector applied to the parent helmfile only defeats this use-case. Because then, once you start splitting your helmfiles, you are unable to rely on label selector to selectively deploy releases anymore.

[mumoshu]

@2ZZ Would you mind if I revert my comment and just make it pass label selector down to sub-helmfiles?

[sgandon]

@mumoshu I am sorry I do not get what you are suggesting. But I think my use case is pretty similar to
@2ZZ .
Basically we have a 'team A' creating a set of charts and they are all gathered in a single helmfile.
And other teams want to use only a subset of this helmfile.
So the idea was to allow for other teams to pick a set of chart of 'teams A' using business labels selectors inside their own helmfiles.
In fact I believe if you allow inheritance like passing down commandline values to sub-helmfile, this creates more confusion and make is more complicated to understand what happens.
And when compositing helmfiles we really need a way to select what to deploy or not for sub-helmfile.

[sgandon]

in my opinion the commandline should only impact the current helmfile for simplicity. That does not mean we can find a way to allow passing argument to sub-helmfile, but this should be done explicitly and not automatically.

[mumoshu]

Does that mean what you want is basically "filter releases according to env values"? 2019年4月8日(月) 0:44 sgandon <notifications@github.com>:

…

in my opinion the commandline should only impact the current helmfile for simplicity. That does not mean we can find a way to allow passing argument to sub-helmfile, but this should be done explicitly and not automatically. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#344 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABV-bheJ70lfglpQAqc_QBzWDvqbgFQks5vehJIgaJpZM4WqR0E> .