helm: dependencies.condition is not behaving correctly in subcharts

Helm’s dependency management solution only handles subchart dependencies one level deep. There is the chart to be installed, and then there are subcharts; there’s no middleground. All subcharts are all treated at the same level, so there’s no notion of “subchart of subchart” handling with regards to value processing.

This was intended by design to prevent the same subchart being included twice in the same chart. In other words, it was designed to prevent chart developers from installing postgres twice in the same release. Instead, it was designed for the chart to share all of the dependencies together, such that if subchart A and subchart B both rely on postgres, they can rely on the same instance rather than installing two separate instances (and therefore double the compute power).

So in other words, the behaviour of having requirements treated at the root level i.e.

postgresql:
  enabled: true

Was an intended design choice of Helm.

I’m not sure how we could accommodate this issue without a significant re-work of how Helm handles subchart dependencies.

I just bumped into this issue too. Forcing a subchart to become aware of all the names the parent could embed it as, is not a scalable solution. I think this is clearly a bug.

Values has supported subchart of subchart all along. That values does it, but conditionals use values, but not respect nesting is odd/unexpected.

I was involved in the design of conditionals early on and I don’t remember any discussions on this design choice.

I think the assumption that postgresql should not be included twice is also not good. I could very well try to install say, keycloak and say, jupyterhub in one overarching chart, and want two separate databases, one per sub component.

It also comes up with some very weird api, where you may have to specify: chart2.postgresql.enabled = true and postgresql.enabled = true as chart2’s templates can refer to its postgresql.enabled (but namespeced under chart2) (for rbac for example)

If you set the one but forget the other, it may cause some very strange things.

Its also impossible for the subchart with the conditional to know all names it can be nested under, as a dependency can be named when included in requirements like so:

  - name: chart2
    alias: mythingy

then it would be mythingy.postgresql.enabled but there’d be no way for a generic chart2 to ever be written/shared, which is the point of nested charts.

Sharing a db is a good feature, but I’m afraid this particular implementation causes more confusion and other issues then it solves for the one feature.

I think this needs to be reconsidered.

FYI, the hackaround to this alluded to in the question (but I want to call out it for others explicitly) is to include the condition in your root chart values exactly as it appears in the subchart requirements.

Eg. instead of

patroni:
  etcd:
    deployChart: true

do:

etcd:
  deployChart: true

Thanks, @jascott1! Your solution did the trick.

I am sure this has been discussed before, but will express my concern regarding the behaviour of the condition option. The vast majority of charts use something like:

condition: postgresql.enabled

Let’s suppose I have a rootChart that depends on artifactory and concourse charts. Both of these charts have condition: postgresql.enabled.

The only way to configure postgresql within the artifactory and concourse charts at the rootChart level is the entry below, which will affect both postgresqls. There is no way to individually configure each of the postgresql.

postgresql:
  enabled: true

What’s more, your solution will not work with alias, because chart’s name is hardcoded.

Finally, the behaviour is also not consistent with the variables used in other parts of the chart.

This sounds like a usability bug to me.

this should now be fixed via https://github.com/helm/helm/pull/4917. https://github.com/helm/helm/issues/3734 raised the same issue/use case. Closing.

Hi @gintautassulskus

Sorry you are having trouble. First thing, you have a typo in your example values file in chart1 for the chart2: key https://github.com/gintautassulskus/chart1/blob/master/values.yaml#L1

Conditions are evaluated from root of the values (for good or ill thats how it is). You can accomplish what (i think) you want by changing chart2’s requirements’ postgresql condition to the following:

condition: chart2.postgresql.enabled,postgresql.enabled

If you install from chart1, the first condition will “win” and control the installation of postgresql. If you install from chart2, there will be no chart1 values so the second condition will “win” and control the installation of postgresql.

+1. I’ve seen some weirdness with aliases too.

We should definitely have a closer look at the requirement subsystem for Helm 3. We’ve already started some work by moving the requirements.yaml into the Chart.yaml as a dependencies field (see the Helm 3 docs on this), but if we’re going to consider re-working the aliases, tags and condition fields, let’s start thinking about it now and discuss potential solutions.

I’d prefer that we only do this for Helm 3, though. I like your suggestion about adding more examples in the docs as a mitigation strategy though, @jascott1. Most of the active Helm contributors are only looking at Helm 3 PRs unless it’s a high prioity security issue or a major blocker/bugfix, so even if someone were to re-work the requirements subsystem for Helm 2 it might be ignored.