Maintain install order between different charts

[hussainsaify]

Hi Team,

We are doing a poc for installing essential services at the time of bootstrapping our kubernetes cluster. We have certain scenarios where some releases should deploy only after another release is deployed successfully.

For example we are installing sealed secrets and other chart uses it to get secrets so part of our requirement is that sealed secrets should be installed before other releases.

Other scenario is we want to install CRD's before installing charts so if we have everything committed on github and we try to bootstrap our cluster through flux then how flux ensures that first CRD is installed and only after it's installation chart gets installed?

Thanks, Hussain

[kferrone]

Since k8s is supposed to be declarative I would think a HelmRelease should just crashloop until needed dependencies show up and a HelmRelease is successful. I have had many conversations about waiting on resources and the answer is always 'that's not kubernetes job'. For example a CI/CD runner like Jenkins, Gitlab, Travis, etc. can do this much easier and cleaner and are meant for this. So essentially if a HelmRelease fails then HelmOperator should just try again and again until it works or it gets deleted. This is the purpose of a Restart Policy in k8s.

I am curious though, does HelmOperator use a Restart Policy and try again if a helm release fails? I guess this would only work if the error was actually from Helm instead of the underlying app.

[hussainsaify]

So, I tried installing cert-manager using flux and it got installed successfully. The order was as expected, Namespace->crd->values configmap ->Helm release

Secondly when there are some dependencies like secrets which are not present then pod will simply wait till it's available.

[lucasvmiguel]

In a cloud-based application, your suggestion would work @hussainsaify

The problem is that the world is not perfect, so we still have to handle application deployment ordering for many apps.

That being said, it'd like to see some kind of way to provide the helm release and its dependencies (secrets, configmaps, other helms, etc)

[kingdonb]

Sorry if your issue remains unresolved. The Helm Operator is in maintenance mode, we recommend everybody upgrades to Flux v2 and Helm Controller.

A new release of Helm Operator is out this week, 1.4.4.

We will continue to support Helm Operator in maintenance mode for an indefinite period of time, and eventually archive this repository.

Please be aware that Flux v2 has a vibrant and active developer community who are actively working through minor releases and delivering new features on the way to General Availability for Flux v2.

In the mean time, this repo will still be monitored, but support is basically limited to migration issues only. I will have to close many issues today without reading them all in detail because of time constraints. If your issue is very important, you are welcome to reopen it, but due to staleness of all issues at this point a new report is more likely to be in order. Please open another issue if you have unresolved problems that prevent your migration in the appropriate Flux v2 repo.

Helm Operator releases will continue as possible for a limited time, as a courtesy for those who still cannot migrate yet, but these are strongly not recommended for ongoing production use as our strict adherence to semver backward compatibility guarantees limit many dependencies and we can only upgrade them so far without breaking compatibility. So there are likely known CVEs that cannot be resolved.

We recommend upgrading to Flux v2 which is actively maintained ASAP.

I am going to go ahead and close every issue at once today, Thanks for participating in Helm Operator and Flux! 💚 💙