Enable coalescing reconciler for more controllers#1691
Enable coalescing reconciler for more controllers#1691k8s-ci-robot merged 2 commits intokubernetes-sigs:mainfrom
Conversation
| registerControllers(ctx, mgr) | ||
| // +kubebuilder:scaffold:builder | ||
|
|
||
| if err := mgr.AddReadyzCheck("webhook", mgr.GetWebhookServer().StartedChecker()); err != nil { |
There was a problem hiding this comment.
@reviewers, please pay close attention here. I believe we were duplicating some code so I removed it, but let me know if there is a good reason for this being called twice (here and line 520)
same thing with mgr.Start (line 304 and line 514)
There was a problem hiding this comment.
Nope. There is no reason to call this twice.
|
/assign @devigned |
main.go
Outdated
| os.Exit(1) | ||
| } | ||
|
|
||
| clusterCache, err := coalescing.NewRequestCache(5 * time.Second) |
There was a problem hiding this comment.
went with 5 seconds since I don't want the reconciles to be too slow but let me know if you think that's too aggressive
devigned
left a comment
There was a problem hiding this comment.
Looks good. Just a couple comments.
| registerControllers(ctx, mgr) | ||
| // +kubebuilder:scaffold:builder | ||
|
|
||
| if err := mgr.AddReadyzCheck("webhook", mgr.GetWebhookServer().StartedChecker()); err != nil { |
There was a problem hiding this comment.
Nope. There is no reason to call this twice.
main.go
Outdated
| } | ||
|
|
||
| func registerControllers(ctx context.Context, mgr manager.Manager) { | ||
| machineCache, err := coalescing.NewRequestCache(5 * time.Second) |
There was a problem hiding this comment.
Did you consider making this a configurable as a cmdline arg?
There was a problem hiding this comment.
I didn't, that would be a good one to be able to make configurable. Do you have any thoughts on whether it should be configurable per controller or just a single value?
There was a problem hiding this comment.
I had made it configurable for both AMP and AMPM. If it's not overkill for cmdline args, I'd vote for per controller.
There was a problem hiding this comment.
AMP and AMPM are both hardcoded right now, I don't think they're configurable.
Per controller makes sense, but it might be overwhelming to the user to be able to configure all of them (or to have to configure each one separately to change all the values). What do you think about one common flag for now, and potentially make it more granular later if the use case arises?
There was a problem hiding this comment.
You are right. I lied. I think I was thinking about doing that, but must have forgot or thought that I already had.
There was a problem hiding this comment.
wishful thinking :)
okay let me know what you think of this:
- using a common var across all the controllers: this is slightly less granular but I think it's a better, easier to understand configuration from a user's perspective (since they're not supposed to know how the code of each controller works), 10 seconds being a middle ground default value.
- the flag name "debouncing-timer" and description, tried to make that as human developer-friendly as possible and tried to describe how it's actually useful (ie. what it does) and not how it does it (ie. "cache").
|
private cluster test had remaining resources after delete /retest |
Enable coalescing reconciler for AzureCluster, AzureMachine, AzureManagedControlPlane, AzureManagedCluster, and AzureManagedMachinePool
6e3d3e5 to
3adb8b5
Compare
|
/retest |
|
How will this work when there are more than one controller instances running? AFAICT, the cache appears to be local to an instance. Does controller manager guarantee that an object's reconciliation request is always sent to the same instance? |
Are you implying a scenario where more than one controller instance is watching and reconciling the same resources? |
Yeah, as in, just scale my capz controller deployment to 2 (or more). |
The controller should have only 1 leader elected based on our manager configuration. I don't know that we should support 2 controllers reconciling the same resources. If 2 controllers are run side by side, I would imagine that each would be responsible for reconciling their own exclusive set of resources. ^ is that assumption incorrect? |
|
Architecture docs to the rescue. |
|
@devigned I think it's a fair assumption. Thanks for the explanation! The only edge case I can think of is when a new leader gets elected, but that's going be rare, and even if it happens, the worst thing that could happen is that the cache will get invalidated, which is fine. |
|
Thanks for bringing this up @shysank, definitely a good scenario to think about. /approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: CecileRobertMichon The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Enable coalescing reconciler for AzureCluster, AzureMachine, AzureManagedControlPlane, AzureManagedCluster, and AzureManagedMachinePool
What type of PR is this?
/kind feature
What this PR does / why we need it: #1332 (devigned@b6b38b0) added a coalescing reconciler to debounce reconciles (in other words, make sure we don't run too many successful reconcile loops in short amounts of time). At the time, it was only enabled for AzureMachinePool and AzureMachinePoolMachine controllers. This PR enables it for more controllers, specifically all the ones that reconcile Azure resources (AzureCluster, AzureMachine, AzureManagedControlPlane, AzureManagedCluster, and AzureManagedMachinePool), in preparation for #1541.
Also fixes some duplicate code in main.go.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #1688
Special notes for your reviewer:
Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.
TODOs:
Release note: