Flux: Order of HelmRelease apply in each sync

[ysaakpr]

Describe the feature
I would like to know if there is any specific order the HelmRelease are applied during a sync operation. Because in my release repo there are 100s of HelmRelease files which are managed via CI/CD pipelines. So if there are changes happened, I would like to keep the helm release to apply the changes in a controlled order, just because of the dependency that One HelmRelease has on another.

What would the new user story look like?
How would the new interaction with Flux look like? E.g.

apiVersion: flux.weave.works/v1beta1
kind: HelmRelease
metadata:
  name: ambassador
  namespace: dev
spec:
  order: 12345(default 1000)
  chart:
    name: ambassador
    repository: https://kubernetes-charts.storage.googleapis.com
    version: 2.8.2

Feel free to add a diagram if that helps explain things.

Expected behaviour
This way we can ensure that some of the helm releases is done at first and some are done at last, and dependency can be managed

[ysaakpr]

This will help to run hook based helm deployment after every sync of the git repo in particular order

[hiddeco]

Thanks for your feature request @ysaakpr, I am afraid that I need to disappoint you with the news that we are not going to integrate this in Flux and/or the Helm operator.

Since Kubernetes fundamentally discourages ordering dependencies, it would be working against Kubernetes to add that kind of mechanism to Flux and/or the Helm operator. It would introduce complexity, and the likelihood is that it would break other things.

---

To not make you leave empty-handed and without a solution: would it be an idea to put your CI in control of changes by e.g. de-automating your HelmRelease resources and performing a controlled fluxctl release within your CI?

[ysaakpr]

I have a strong feeling that, though Kubernetes is fundamentally discouraging, Fluxcd is not a Kubernetes tool, its CD framework. By the name its a CD framework and tooling. And I believe in CI and CD sequence of operation is a must.

As you mentioned I can leverage this by integrating with my CI pipelines. But creates too much tool switch to just achieve the pipeline behaviour, is that not against the 'bounded context' principle of application design.

I fundamentally vote for this, since it gives a better organisation of the release artefacts and the order of release.

I would like to reopen this and let's have a discussion with the community. I would like to contribute either way by forking it or in the same if the authors permit.

[adam-carbone]

Ya this is a little wierd because spinnaker allows you to order your pipelines

[marshallford]

The istio-init and istio helm chart require order to install correctly. In the same vein how can I ensure flux installs CRDs before a helm chart (for example cert-manager or flux itself)?

[varac]

In the same vein how can I ensure flux installs CRDs before a helm chart (for example cert-manager or flux itself)?

@marshallford I'm also in desperate need to chart ordering, but CRDs can now get installed directly with helm3, see the cert-manager CRD installation with helm3 issue.

[marshallford]

@varac, Thanks for the tip. To answer my own question above regarding the pair of Istio charts: I was able to install Istio with Flux by relying on the Istio Operator API.