Can One HelmRelease Act as an Umbrella for Others?

[Ashish7812]

Question

As HelmRelease is a CR. is it advisable to embed one HelmRelase CR in another HelmRelease CR?

Usecase

1. We have three HelmRelease CRs with defined dependencies, for example: HelmRelease_c → HelmRelease_b → HelmRelease_a.
2. All three HelmReleases are placed in a single YAML file. Now, I want to pass some values across these three HelmReleases in the file.
3. My idea is to treat these three HelmReleases as part of another chart and reference them in a new HelmRelease CR. This new HelmRelease would act as an umbrella for the inner three HelmReleases and accept values from the user.

any suggestion?

[matheuscscp]

Yes, no issues with that

[Ashish7812]

@matheuscscp In this way how deep can we nest the HelmRelease CR's? The usecase is If I do any opeation on the top HelmRelease CR inner HelmRelease CR should also go through the same operation.

Ex: If I rollback the Outer HelmRelease CR then the inner HelmRelease CR should also rollback. will it happen?

[matheuscscp]

The helm-controller will reconcile a HelmRelease when:

• The inputs for the release change. This could be the chart version changing, or the values passed to the release changing, etc.
• You force-reconcile the release with flux reconcile hr --force.
• The .spec.install.strategy and/or .spec.upgrade.strategy are set to RetryOnFailure and a reconciliation is triggered (through whatever means, flux reconcile hr, Receiver, controller restart, etc.)

A Helm rollback on the "umbrella" HelmRelease will not propagate a Helm rollback action to children HelmReleases, but rather a Helm roll-forward action (install/upgrade) if the inputs produced by the "umbrella" release manifests change from the perspective of the children HelmReleases.

You can have as many levels as you want. The controller is agnostic and doesn't know that a HelmRelease is deploying other HelmReleases (hence why the Helm rollback propagation does not happen).

[Ashish7812]

Thanks @matheuscscp for the clarification. I have one more question on the way we consume the configmap in the HelmRelease.

I have the following setup

The helm controller is deployed in the management cluster. I performed two tests for the below scenario

Test 1 (Deploy the two interdependent helm release in same management cluster)

I have two HelmReleases

1. One creates the some ACK resources and it produces a configmap.
2. The second HelmRelease is dependent on the first HelmRelease and it consumes the configmap produced by the first one.

This setup is working fine as the configmap and the helmreleases are in the same namespace and in the same cluster also.

Test 2 (I want to deploy in the target cluster from the management cluster)

This scenario I have not tested yet so looking for your input whether this scenario is supported in Flux?

The cofigmap will be created in the target cluster but the helm release is present in the management cluster.
So the dependent helm release will not be able to pick up the config map as it is present in target cluster. (This is my assumption.)

Can we achieve the above scenario using flux?

[matheuscscp]

The cofigmap will be created in the target cluster but the helm release is present in the management cluster.
So the dependent helm release will not be able to pick up the config map as it is present in target cluster. (This is my assumption.)

Correct.

[Ashish7812]

@matheuscscp Can helm-controller support this scenario?

[matheuscscp]

I'm not sure... Do you have a proposal?

[Ashish7812]

Thanks @matheuscscp for following up. I am not aware of the helm-controller internals. I can think of the following approach.

In the HelmRelease custom resource it can accept a new field called 'produces' something like this

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: podinfo-remote
  namespace: default
spec:
  produces: ----------> an optional field
   configmap:
    name: sample-cm
    namespace: default

Sequence of steps

1. Helm controller will create the config map in the specified namespace and in the cluster specified by kubeconfig.
2. Install the chart.
3. It is the responsibility of the k8 resources present in the chart to write to the configmap. (The name of the configmap can be supplied in to the chart via the values section.)
4. Once the chart is installed, helm controller can just sync it back to the management cluster. The config map will be created in the same namespace as specified in the CR.

This way the dependent helm release can just refer the config map in the management cluster.