You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I like the option to have the helm-controller update my charts according to the semantic versioning specification. For most of my charts, I use this to automatically update when a new patch release is published.
The current approach will automatically apply updates when the reconciliation interval is hit. This can lead to downtimes within working hours. My recommendation is to replace the time interval (Duration) with a cron schedule. If this was realized, we could still express regular interval, but could also restrict reconciliation to specific maintenance windows.
The text was updated successfully, but these errors were encountered:
Hi, replacing reconciliation interval with a cron schedule may not be feasible because of the design of flux and most of the other kubernetes controllers that use controller-runtime. The underlying tooling requires the usage of a reconciliation interval which is of type Duration as you've already seen. And there's a default cache sync period of 10 hours, which will fetch object state from the kubernetes API server and trigger a reconciliation. This may be more related to the gating feature request in flux, refer fluxcd/flux2#3158 for a proposal and discussion around this.
Although we can't have a cron schedule for interval, to an extent, I think your need is to separate the HelmRelease reconciliation and HelmChart reconciliation so that the workloads remain correctly deployed and well managed as per the declared expectations, but the updates to the charts are checked at a different time. This is already feasible by specifying a different interval for the HelmChart that a HelmRelease creates. From the HelmRelease chart template docs, you can see that it embeds the HelmChart API. And the HelmChart docs show that it supports its own reconciliation interval. By default, when no interval is specified for the chart in HelmRelease, the HelmRelease reconciliation interval is used, refer https://github.com/fluxcd/helm-controller/blob/v0.37.4/api/v2beta2/helmrelease_types.go#L342-L343 .
Example of different reconciliation intervals in a HelmRelease:
Another way of triggering a reconciliation on a schedule would be to use the flux notification-controller receiver and send an http request to the receiver by some other means which can then trigger a reconciliation of the HelmChart. This is not the best and perfect solution for the gating problem, but if you just need some level of scheduled reconciliations, this would work.
In case of HelmCharts, the HelmRepository may also need to be considered as HelmRepository downloads the new helm index file which contains the details about the helm charts. So you'd need ensure that HelmRepository reconciliations are scheduled whenever you need it to update. For OCI helm charts, HelmRepository don't do anything. You'll need to consider the reconciliation of HelmCharts in this case.
As discussed in the flux gating proposal, ideally, suspending the HelmChart would be the best solution. But at present, we don't have any native way of doing that. If you can write your own tooling, you can run some automation that suspends HelmChart and resumes it at a schedule and again suspends it to make sure it doesn't pull any update outside the schedule.
I hope this provides enough context about the previous discussions we had for such a feature.
I like the option to have the
helm-controller
update my charts according to the semantic versioning specification. For most of my charts, I use this to automatically update when a new patch release is published.The current approach will automatically apply updates when the reconciliation interval is hit. This can lead to downtimes within working hours. My recommendation is to replace the time interval (Duration) with a cron schedule. If this was realized, we could still express regular interval, but could also restrict reconciliation to specific maintenance windows.
The text was updated successfully, but these errors were encountered: