cache.ErrRequeue advertised itself as a way to requeue failures on a
FIFO, but it suffers the same problems as AddIfNotPresent. If we do
requeue an item at the end, we'll move the informer back in time. If we
requeue at the beginning we'll simply wedge FIFO.
We didn't find examples in the wild, but by removing the error type
those impacted will get a compile error and get to decide what action is
most appropriate for their failure. Most of the time, proceeding to the
next item is best.
Kubernetes-commit: 238c32a1d9b2c72d648193fa8642a53a2884975f
Logically a cache.Queue.AddIfNotPresent means that the informer can move
back in time since an older item is placed after newer items. The
alternative of placing errors at the head of the queue leads to
indefinite memory growth and repeated failures on retry.
Luckily this behavior was behind RetryOnError, which was always set to
false and impossible for normal users to set to true. By removing the
function and setting, impacted users (none found in a github search)
will get a compile failure.
Kubernetes-commit: 8e77ac000131019d5aa49c19aa1f477f6dac4d59
This is useful to both reduce the code complexity, and to ensure clients
get the "newest" version of an object known when its deleted. This is
all best-effort, but for clients it makes more sense giving them the
newest object they observed rather than an old one.
This is especially useful when an object is recreated. eg.
Object A with key K is in the KnownObjects store;
- DELETE delta for A is queued with key K
- CREATE delta for B is queued with key K
- Replace without any object with key K in it.
In this situation its better to create a DELETE delta with
DeletedFinalStateUnknown with B (with this patch), than it is to give
the client an DeletedFinalStateUnknown with A (without this patch).
Signed-off-by: Odin Ugedal <ougedal@palantir.com>
Signed-off-by: Odin Ugedal <odin@uged.al>
Kubernetes-commit: 7bcc3e00fc28b2548886d04639a2e352ab37fb55
This fixes an issue where a relist could result in a DELETED delta
with an object wrapped in a DeletedFinalStateUnknown object; and then on
the next relist, it would wrap that object inside another
DeletedFinalStateUnknown, leaving the user with a "double" layer
of DeletedFinalStateUnknown's.
Signed-off-by: Odin Ugedal <ougedal@palantir.com>
Signed-off-by: Odin Ugedal <odin@uged.al>
Kubernetes-commit: 0bf0546d9f75d92c801e81c9f7adf040bba64102
This fixes a race condition when a "short lived" object
is created and the create event is still present on the queue
when a relist replaces the state. Previously that would lead in the
object being leaked.
The way this could happen is roughly;
1. new Object is added O, agent gets CREATED event for it
2. watch is terminated, and the agent runs a new list, L
3. CREATE event for O is still on the queue to be processed.
4. informer replaces the old data in store with L, and O is not in L
- Since O is not in the store, and not in the list L, no DELETED event
is queued
5. CREATE event for O is still on the queue to be processed.
6. CREATE event for O is processed
7. O is <leaked>; its present in the cache but not in k8s.
With this patch, on step 4. above it would create a DELETED event
ensuring that the object will be removed.
Signed-off-by: Odin Ugedal <ougedal@palantir.com>
Signed-off-by: Odin Ugedal <odin@uged.al>
Kubernetes-commit: 25d77218acdac2f793071add9ea878b08c7d328b
* Add tracker types and tests
* Modify ResourceEventHandler interface's OnAdd member
* Add additional ResourceEventHandlerDetailedFuncs struct
* Fix SharedInformer to let users track HasSynced for their handlers
* Fix in-tree controllers which weren't computing HasSynced correctly
* Deprecate the cache.Pop function
Kubernetes-commit: 8100efc7b3122ad119ee8fa4bbbedef3b90f2e0d
Fixes: kubernetes#90581 (the first part)
When `Close()` is invoked on an empty queue, the control loop inside `Pop()` has a small chance of missing the signal and blocks indefinitely due to a race condition. This PR eliminates the race and allows the control loop inside any blocking `Pop()` to successfully exit after Close() is called.
Kubernetes-commit: d8b90955519d10b99415515f8314dd6d35caae8d
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.
Kubernetes-commit: ca1eeb99b530a6d76b464dad545abc18d4508c49
Fix DeltaFIFO bug that caused the sync delta created by a relist
for object ID X to be dropped if the DeltaFIFO already stored a
Delete delta for X. This caused SharedIndexInformer to miss create
notifications. Also, add unit test to expose the bug.
Kubernetes-commit: 9e4be54895e8c0655408b4766cd78de17b6d5b7c
Nobody uses it; the one or two older users from 1.4/1.5 timeframe
were removed for 1.6. It's also poorly understood and the sole
example is in the testcases, and it's pretty incomplete.
If anyone really wants compression, they can revert this PR.
Kubernetes-commit: a56c8f50cb9b9bfdb92bc5f005a48f8df5afadb9
