This commit adds a rate limiter to the ManagedOSVersionChannel controller to prevent
stacking reconcile loops over the same resource in fast rates (doesn't make sense for a
ManagedOSVersionChannel). By default the controller runtime already includes an
equivalent rate limiter, but starts in the range of milliseconds, starting the exponential
rate limiter in the range of seconds is more than enough in this context.
In addition it drops the failures counter in the resource. This counter was supposed to
be used to limit the number attempts to sync in case of failure. This was a bad design,
status should not keep a counter like this as any change in status triggers a new
immediate reconcile loop, hence the counter was reaching the maximum as fast as the
controller runtime was executing reconcile loops without any rate limiter (rate limiter
applies only when there are no changes including status).
For now I think we can just live without the setting any maxium for failures. If we ever
need it I believe it should be coded and tracked within the controller itself, not in each
resource as this prevents the reconcile loop of being idempotent. Alternatively we could
prevent triggering the reconcile loop on status changes, however this prevents
reconciling if any third party (or user from the kubectl client) changes a resource status.
Fixes#257
Part of #240
Signed-off-by: David Cassany <dcassany@suse.com>
5757f2d82f