-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Prevent redundant Chart releases during helm-operator startup #1040
Comments
@squaremo for Helm charts with hooks this is a big deal. For example on charts that use pre-install and post-install hooks to run migrations, clustering init, etc this behaviour could potentially break things. |
@stefanprodan I don't think anyone should be relying on Helm's hooks being run at exactly the right times, or exactly the right number of times, irrespective of flux or the flux helm operator. In any case, we should try to avoid doing extra work, and making the situation worse, at least. After #1240 is merged, the helm op will
1.) is driven by the cluster observer (in operator.go), i.e., it reacts to the resources changing, and effectively runs straight away. When starting, any existing FluxHelmRelease resources are considered as being new, and will be updated -- it's likely this that is considered the redundant update. One way to avoid it would be to run the observer-driven releases through the same reconciliation code as 3), i.e., to install if missing and upgrade only if it would make a difference. |
Yep; here's a log from helm-operator as it starts up, after nothing in the cluster or in git has changed:
There's a bunch of releases done there that aren't strictly necessary, triggered by the |
I think the CR object has a timestamp for when it was last updated, maybe we could use that at startup to avoid this. |
After #1254, helm-op always checks to see whether a release will change anything. That avoids the redundant releases mentioned here. |
Problem
Currently, when the helm-operator restarts, all Chart releases within the cluster are, possibly redundantly, deployed.
A/C
When the helm-operator starts, only necessary release upgrades should be performed.
The text was updated successfully, but these errors were encountered: