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. |
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 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 DetailsNeeds 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 |
The Replaced event is emitted when the informer's watch is disrupted and requires a re-list. If this re-list results in a change, the change is *swallowed* unless either Sync events or Replaced events are enabled. Given that Sync is generally disabled, we should accept the Replaced event type. (see: kubernetes/kubernetes#86015 ) Signed-off-by: Casey Callendrello <cdc@isovalent.com>
The Replaced event is emitted when the informer's watch is disrupted and requires a re-list. If this re-list results in a change, the change is *swallowed* unless either Sync events or Replaced events are enabled. Given that Sync is generally disabled, we should accept the Replaced event type. (see: kubernetes/kubernetes#86015 ) Signed-off-by: Casey Callendrello <cdc@isovalent.com>
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