-
Notifications
You must be signed in to change notification settings - Fork 187
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
Throttle reconciliation in case of error #203
Comments
We use the controller-runtime exponential backoff, the retries interval is slowly increased. |
In this case I see no point in that, these kind of errors don't go away until the next source sync. This only fixes temporary issues. |
Well a kubectl apply will fail if your master nodes are restarting or if there is a temporary connection errors between pods and Kubernetes API service. |
Well the reconciliation with exponential backoff is not really problem but in combination with slack alerts quite unusable, you end up with way too many alerts. Is there a workaround for the notification controller? If not maybe the solution is better placed there, I've only seen |
I think this can be a feature request for notification-controller, if we make it into a statefulset, then it can store events in a database and prevent spurious events being send. |
@raffis with this bug fixed, there will be no more Slack spam on kubectl apply errors, once the reconciliation status can be persisted in etcd, the controller will retry at the configured interval. |
If there is an error it looks like the configured interval does not get considered.
I have a
10m
configured interval and one error in a manifest and see a reconciliation every ~10s.Which also leads to a slack alert for each. (Also the slack alerts are useless because of #190, I don't see the actual error in the notification nor the log because of #202).
The text was updated successfully, but these errors were encountered: