Delay GitRepo status reconciliations from bundle status changes #3558
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refers to #3576
Similar to the idea behind #3401, add a delay to GitRepo bundle updates caused by Bundle status changes, so that multiple successive triggers are aggregated into a single execution. This helps mitigating the surge in GitRepo status changes when a new Bundle and/or Cluster is added, whose BundleDeployments updates cascade-update Bundles and finally the parent GitRepo, especially at scale.
Additional Information
I used an alternative approach than the one used in #3401 (which hijacks the handler), and instead tweak the behavior of the queue passed to the handler instead. The reason for this is that in the other case, the handler only implemented the
Generic
event method, while this case is more complex.Also, while the
controller.Options
allow tweaking the the workqueue creation, I'm discarding this, in order to apply this behavior exclusively for "bundle-originated" triggering.