Make it clear that periodic resyncs fire update notifications, not
create notifications as the old comments incorrectly stated.
Kubernetes-commit: 3ae8c864de24a2ad42321c9cbd71099a2b6dcef3
The `recorder.PastEventf` method wasn't actually working as advertised.
It was supposed to accept a timestamp, which would be used when
generating the event. However, as the
[source code](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/client-go/tools/record/event.go#L316)
shows, this `timestamp` was never actually used.
In other words, `PastEventf` is identical to `Eventf`.
We have two options: one would be to fix `PastEventf` so that it works
as advertised. The other would be to delete `PastEventf` and only
support `Eventf`.
Ultimately, I could only find one use of `PastEventf` in the code base,
so I propose we just delete `PastEventf` and convert all uses to
`Eventf`.
Kubernetes-commit: 92940fa80d67593c7a2333267da4424c8b45ac88
- Added thread_safe_store_test exercising new index backing string set delete at 0 functionality.
- TestThreadSafeStoreDeleteRemovesEmptySetsFromIndex logic nesting inverted.
- Added test case for usage of an index where post element delete there is non-zero count of elements and expect the set to still exist.
- Fixed date.
- Fixed awprice nits.
- Fix bazel.
Kubernetes-commit: 29a051388a719e0359969b8431de8e38e955e2a6
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
It was previously possible to instantiate `Reflector` with
`*unstructured.Unstructured` as the expected type but this did not
support checking that event objects were of the correct API
type (e.g. if event object was `v1.Pod` in `Unstructured` form but
`v1.Service` was expected). This commit adds support for providing a
GVK via an `Unstructured` expected type to compare with the GVK of
event objects. The GVK will also be used in reflector log output.
Kubernetes-commit: 237dbfd8ad322dfcad4bd4d5345368480c22d82f
If a cache was already synced, cache.WaitForCacheSync would
always take 100ms to complete because the PollUntil method will
sleep first before checking the condition. Switching to
PollImmediateUntil will ensure already synced caches will return
immediately. For code that has, for example, 20 informers, the time
to check the cache was in sync would take at least 2 seconds, but with
this change it can be as fast as you can actually load the data.
Signed-off-by: Darren Shepherd <darren@rancher.com>
Kubernetes-commit: 8a58f332dd62b68ae22c67585002defe6aeb4b04
Added definition of "collection states" and noted that informer cache
queries are answered against these.
Also added an explicit note that the concept of object identity used
in the contract here does _not_ include ObjectMeta.UID.
Also updated the description of the notifications received by a
client, to account for the fact that a client can be added after the
informer starts running.
Added references to `MetaNamespaceKeyFunc` and
`SplitMetaNamespaceKey`.
Noted that a client must process each notification promptly and added
a referral to workqueue.
Made a couple other minor clarifications and corrections.
Kubernetes-commit: 848301e11a8558f6a90e2fada870a91baace812a
