-
Notifications
You must be signed in to change notification settings - Fork 40.1k
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
informers: Don't treat relist same as sync #86015
informers: Don't treat relist same as sync #86015
Conversation
e77bb56
to
c3567d0
Compare
Many thanks to @sttts, who helped me understand exactly where to look in the SharedInformer when faced with an "impossible" sequence of log lines. |
Can that be split to a separate PR? That's separate from the bug fix, correct? We've previously decided against teaching informers about uids, would like to consider that separately and not backport that. |
staging/src/k8s.io/client-go/tools/cache/testing/fake_controller_source.go
Outdated
Show resolved
Hide resolved
It's not separate to this bug fix; @sttts suggested that I split it out since it's not strictly necessary. There are two points for consideration:
Additionally, the elision only takes place for Replace events - so it's not a large change. |
c3567d0
to
c174e22
Compare
resourceVersion is unique per resource type (it has to be, since we use it for list requests across resource instances), so it cannot repeat on a delete/recreate |
We should split it to a separate PR, as it needs more discussion, and even if accepted, I would not expect to backport that part. |
Ack. Removed UID check; doesn't affect correctness. |
Understood. The open question to me is: is it OK to send resync updates to handlers that don't want them? If so, then we don't need the last commit. Otherwise we do. |
I think it is probably good to make the distinction, but this will be disruptive to users, potentially very disruptive. Therefore, I think you need to wire an option or provide a 2nd constructor or something, so that existing code can continue to work the same with no changes. |
@lavalamp I don't quite follow - what sort of option were you thinking of? To be clear here, this PR doesn't disable resyncs or change the standard informer behavior at all. It just ensures we don't miss updates due to a re-List. AFAICT, the question is whether or not we should expose the re-List due to disruption to the handlers. |
There can be direct clients of this. The fact that we can make corresponding changes in the informer to preserve its behavior makes your life much easier though. |
As an alternative to adding a new Delta type, we could "fix" this in the SharedInformer by cheating a bit, and treating Sync as Updated if the object differs from the store. |
/lgtm |
unit test failure is legitimate:
|
/lgtm cancel |
whoops, fixing |
0279ec0
to
c889d9d
Compare
/retest |
1 similar comment
/retest |
Overall, great change-- I hate to ask for something but the name is unchangeable once we cut a client-go release, so... |
Background: Before this change, DeltaFIFO emits the Sync DeltaType on Resync() and Replace(). Seperately, the SharedInformer will only pass that event on to handlers that have a ResyncInterval and are due for Resync. This can cause updates to be lost if an object changes as part of the Replace(), as it may be incorrectly discarded if the handler does not want a Resync. What this change does: Creates a new DeltaType, Replaced, which is emitted by DeltaFIFO on Replace(). For backwards compatability concerns, the old behavior of always emitting Sync is preserved unless explicity overridden. As a result, if an object changes (or is added) on Replace(), now all SharedInformer handlers will get a correct Add() or Update() notification. One additional side-effect is that handlers which do not ever want Resyncs will now see them for all objects that have not changed during the Replace.
c889d9d
to
ca1eeb9
Compare
OK, rename done. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: liggitt, squeed 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 |
/retest Review the full test history for this PR. Silence the bot with an |
2 similar comments
/retest Review the full test history for this PR. Silence the bot with an |
/retest Review the full test history for this PR. Silence the bot with an |
What type of PR is this?
/kind bug
What this PR does / why we need it:
Background:
Before this change, DeltaFIFO emits the Sync DeltaType on Resync() and Replace(). Seperately, the SharedInformer will only pass that event on to handlers that have a ResyncInterval and are due for Resync. This can cause updates to be lost if an object changes as part of the Replace(), as it may be incorrectly discarded if the handler does not want a Resync.
What this change does:
Creates a new DeltaType, Replaced, which is emitted by DeltaFIFO on Replace(). For backwards compatability concerns, the old behavior of always emitting Sync is preserved unless explicity overridden.
As a result, if an object changes (or is added) on Replace(), now all SharedInformer handlers will get a correct Add() or Update() notification.
One additional side-effect is that handlers which do not ever want Resyncs will now see them for all objects that have not changed during the Replace.
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
/cc @sttts
/cc @liggitt