Set namespace for subcharts using values.yaml

[crubier]

This is a feature request, related to #2813 .

I have this use case with strong operational constraints (integration with terraform on one side, and with gitlab on the other side), where I would like to be able to specify namespaces of subcharts, for example by using a values.yaml like this:

my-subchart-1:
    enabled: true
    namespace: gitlab-managed-apps
    foor: bar

my-subchart-2:
    enabled: true
    namespace: my-namespace
    bar: foo

I tried it at first, not doubting that this would work, as I expected this behaviour. But I was surprised to see that it does not work, even though it "feels helm idiomatic".

I also believe that it would not be much effort to implement, but I might be mistaken!

[hickeyma]

@bacongobbler with the addition of State Management and the removal of Tiller in v3, will it be possible to use multiple namespaces in the one release?

[hickeyma]

@crubier For v2, you could install each namespace individually using --skip-dependencies or with conditions

[crubier]

@hickeyma using tags might be a fair workaround for me in this case. Tag subcharts with different values and execute one release per namespace

[bacongobbler]

This feels like a solid use case for helmfile. I don't think this will be resolved in Helm 3 as the original post is requesting a new feature within requirements.yaml (or Chart.yaml in Helm 3). We haven't ironed out the details for managing a single release across multiple namespaces, though several community members have written tools to manage that state across the cluster.

See also #980 for some background context/disucssion on this topic.

[crubier]

@bacongobbler this is not use case for helmfile, as I don't really want to add an additional third party alpha dependency to this (already quite complex) stack, that will have to run in various environments.

Using tags and multiple releases allows me to work around, but with a pretty high complexity.

[nicorikken]

@crubier the proposal you outlined would suit are use-case and looks very ergonomic. I too tried this, assuming that would work, but no.
When it comes to combining charts, Helm is missing some key features. We need these features to start sharing and combining more templates in the community, rather than everyone having to build their own.

[nicorikken]

I've been able to work around this by introducing an namespaceOverride value in a chart helm/charts#15202 ,picked up by the _helpers.tpl. I combine this with the alias: option in the values.yaml of the main chart to duplicate the subcharts under different names as to configure them differently.

[MichaelMitchellM]

Is there any update on support for this?

[kevupton]

This would definitely be useful in my scenario where I have mutliple helm subcharts across different namespaces.

[sadoMasupilami]

would be useful for cases like deploying external-dns or aws-alb-ingress together with your stack as options.

[mforutan]

The approach I took was to combine global variables with namespaceOverride so it can be overridden from multiple level in umbrella charts,

In the scenario below when an umbrella chart has a dependency and its dependency has its own dependency, just overriding nemespace on the first level is not flexible enough and will result in moving chart-1 to name-space-2 but chart-2 will be still in the name-space-1:

top-umbrella-chart:
- namespace: name-space-1
- values.yaml:
  chart-1:
    namespaceOverride: name-space-2
- dependencies:
    - chart-1:
      dependencies:
      - chart-2:

to resolve this, I am using global.namespaceOverride so it can push down to the lower level:

top-umbrella-chart:
- namespace: name-space-1
- values.yaml:
  global.namespaceOverride: name-space-1
  chart-1:
    global.namespaceOverride: name-space-2
- dependencies:
    - chart-1:
      dependencies:
      - chart-2:

in this case, chart-2 will follow the same namespace from chart-1 instead of using release.namespace

An example of using this was merged for stable/mongodb-replicaset chart with values.yaml file and _helper.tpl function,

Do you think this can be a possible solution for this issue?

[bacongobbler]

Please use helmfile to handle management of multiple releases in separate namespaces. Chart dependencies are all rendered and deployed in the same namespace as the release. Supporting this would result in a massive undertaking of Helm's architecture, and is a use case that is already solved by another tool in the community ecosystem.

[MichaelMitchellM]

@bacongobbler Please say which tool that is.

[bacongobbler]

https://github.com/roboll/helmfile

[yellowmegaman]

Helmfile does not support atomic deployment of all charts. (1 chart deployment failed = rollback all other).

Helm seem to support that with dependencies deployment, but we can't set namespace for particular dependency.

Would love to see this reopened, because if you want to deploy particular version of ingress controller, database, vault and your backend, you need to add parameters to all charts to get namespace from values.

[yanchenko-igor]

Helmfile does not support atomic deployment of all charts. (1 chart deployment failed = rollback all other).

Helm seem to support that with dependencies deployment, but we can't set namespace for particular dependency.

Would love to see this reopened, because if you want to deploy particular version of ingress controller, database, vault and your backend, you need to add parameters to all charts to get namespace from values.

I believe you would have better luck talking with helm chart authors, they can get the NamespaceOverride value that is used when defined.

[yellowmegaman]

@yanchenko-igor Thanks for chipping in.
I don't think it is a sustainable solution, way too many charts are created with more or less default settings (e.g. helm create somechart), and considering release cycles and discussions, it can take ages to get that propagated.

@bacongobbler Using another tool is added complexity and Helmfile definition files, hence Helm itself is a perfect tool for that job. Current lack this feature limits user's ability to reuse existing charts as dependencies.