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

Manually enforce reconciliation in the face of exhausted retry contingent #366

Closed
makkes opened this issue Nov 26, 2021 · 4 comments · Fixed by #823
Closed

Manually enforce reconciliation in the face of exhausted retry contingent #366

makkes opened this issue Nov 26, 2021 · 4 comments · Fixed by #823
Labels
area/helm Helm related issues and pull requests area/ux In pursuit of a delightful user experience enhancement New feature or request

Comments

@makkes
Copy link
Member

makkes commented Nov 26, 2021

The documentation says that

The reconciler can be told to reconcile the HelmRelease outside of the specified interval by annotating the object with a reconcile.fluxcd.io/requestedAt annotation
but that only works when the number of retries has not been exhausted, yet. Currently, the only way to enforce another reconciliation of a HelmRelease is a deletion of the resource and waiting on it getting created again from Git (or manually if no Git repo is involved).

I would like to propose changing the behaviour of the reconcile.fluxcd.io/requestedAt annotation to always reconcile even if the number of retries is exhausted.

@makkes makkes added area/helm Helm related issues and pull requests area/ux In pursuit of a delightful user experience enhancement New feature or request labels Nov 26, 2021
@stefanprodan
Copy link
Member

stefanprodan commented Nov 26, 2021

I would like to propose changing the behaviour of the reconcile.fluxcd.io/requestedAt annotation to always reconcile even if the number of retries is exhausted.

I agree, right now only the HelmRelease Kind behaves like this, but I guess @hiddeco will have a different opinion.

@hiddeco
Copy link
Member

hiddeco commented Nov 26, 2021

[..] right now only the HelmRelease Kind behaves like this, [..]

This is not true, the requestedAt annotation requests a reconciliation, which the controller does like all other controllers. Where the controller differs from e.g. the kustomize-controller however, is that it does not perform a blind apply (or Helm release in this case) nor endless retry, because this would cause the storage to drift.

Due to this, and because the release itself is a long running process, I think it should be a separate annotation which on the CLI side is used as a replacement for requestedAt, when you run flux reconcile ... --force. Which effectively disables the remediation strategy (and limitations) for that reconcile.

@stefanprodan
Copy link
Member

because this would cause the storage to drift.

Right I forgot about this, so we need a different annotation for the helm API only, that the CLI sets when --force is set.

@hiddeco
Copy link
Member

hiddeco commented Nov 26, 2021

The question is if the annotation only ignores the failure count of the defined remediation strategy (remediateAt?), or if it does more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/helm Helm related issues and pull requests area/ux In pursuit of a delightful user experience enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants