-
Notifications
You must be signed in to change notification settings - Fork 560
WIP: refactor resolution sync #2400
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
Conversation
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: njhale The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
7f9251a
to
2239029
Compare
shouldUpdate := false | ||
for _, sub := range subs { | ||
shouldUpdate = shouldUpdate || !o.nothingToUpdate(logger, sub) | ||
if o.sourcesLastUpdate.Before(lastResolution.Time) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we discussed this on the Slack thread, blocking resolution on unreliable timestamp is problematic. I have recently remove this timestamp check due to blocked/delayed upgrade when subscription spec change. The only time we should skip resolution is where there is a pending installation which is checked above this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dinhxuanvu we've noted hotlooping in this sync handler in master. I'm not convinced it's unrelated to the removal of the timestamp check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to check out what hotloop situation that you are referring to. However, given if there is nothing changed, resolver should resolve into nothing which in turn shouldn't lead into any subscription changes. I'm not convinced just because we let resolver run whenever namespace sync happens will cause hotlooping. If we are talking about too many resync, then there is a ratelimiting setting for this in place if I recall correctly.
Signed-off-by: Nick Hale <[email protected]>
2239029
to
05de665
Compare
@njhale: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Closing out for now. Will try again at some point. |
Description of the change:
An attempt to simplify resolution syncing.