Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Replace reconciliation interval with cron schedule in HelmRelease CRD #920

Open
thewilli opened this issue Mar 22, 2024 · 1 comment
Labels
wontfix This will not be worked on

Comments

@thewilli
Copy link

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.

@darkowlzz
Copy link
Contributor

darkowlzz commented Mar 22, 2024

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:

spec:
  interval: 10m
  chart:
    spec:
      chart: podinfo
      version: '6.5.*'
      sourceRef:
        kind: HelmRepository
        name: podinfo
      interval: 24h
  ...

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.

@souleb souleb added the wontfix This will not be worked on label Apr 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

3 participants