The watch.Interface design is hard to change, because it would break
most client-go users that perform watches. So instead of changing the
interface to be more user friendly, this change updates the method
comments to explain the different responsibilities of the consumer
(client user) and the producer (interface implementer).
Kubernetes-commit: 1f35231a1d4f7b8586a7ec589c799729eeb4f7c4
- Extract watchWithResync to simplify ListAndWatch
- Wrap watchHandler with two variants, one for WatchList and one for
just Watch.
- Replace a bool pointer arg with a bool arg and bool return, to
improve readability.
- Use errors.Is to satisfy the linter
- Use %w to wrap the store.Replace error, to allow unwrapping.
Kubernetes-commit: 65fc1bb463c85a4c85e619bf7acac9503e23a253
- Switch to using the ProxyWatcher to validate the dance between
closing the stop channel and closing the result channel.
- Use the new clientfeaturestesting.SetFeatureDuringTest to test with
the WatchListClient enabled and disabled. These should result in
almost the exact same output events from the informer
(list ordering not garenteed), but with different input events
recieved from the apiserver.
Kubernetes-commit: 28e3a728e5e6fe651d7a17839d33ce42204c0b4e
- Add tests to confirm that Stop is always called.
- Add TODOs to show were Stop is not currently being called
(to fix in a future PR)
Kubernetes-commit: ab5aa4762fd5206d0dbd8412d7c6f3b76533a122
The previous attempt to fix this in
6aa779f4ed (diff-efa2cd1347df22ace5a516ea794152d00ef2a079db135c81787ed920ecb73658)
didn't address the root cause (or perhaps created it, not sure): the goroutine
must not be started if watch creation failed.
Instead, the error gets logged (as before) and an empty watch gets returned to
the caller (new). This is necessary because the function doesn't have an error
return value and changing that now would be disruptive. The empty watch is
valid and usable, so callers won't crash when they calls Stop.
This showed up recently in failed unit tests, probably because test
cancellation makes this error more likely:
"Unable start event watcher (will not retry!)" err="broadcaster already
stopped" logger="TestGarbageCollectorConstruction leaked goroutine"
The logger value and a preceding warning show that this occurs after test
completion.
Kubernetes-commit: 080432c46a7a49c3abf86d7fc5f2a5d7abc92239
Constructing a Broadcaster already starts a watch which runs in the
background. Shutdown must be called to avoid leaking the goroutine. Providing
a context was supposed to remove the need to call Shutdown, but that did not
actually work because the logic for "must check for cancellation" was
accidentally inverted.
While at it, structured log output also gets tested together with checking for
goroutine leaks.
Kubernetes-commit: ff779f1cb56cf896405e52f7923188b99b88bb00
the signature of the method was tightly connected to the reflector,
making it difficult to use for anything other than a reflector.
this simple refactor makes the method more generic.
Kubernetes-commit: 83c7542abc8c542c01ecb67376f134b2071c5304
Hang when canceling leader election information.
Occasionally, two leaders may run simultaneously.
Kubernetes-commit: b6b46a0e00682517d2ca7b7e9c2706b8e407e52e
In particular, document that ListAllByNamespace delegates to ListAll
if no namespace is specified.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
Kubernetes-commit: 54e899317ef46e3b70827cacee244717022db0ad
The path module has a few different functions:
Clean, Split, Join, Ext, Dir, Base, IsAbs. These functions do not
take into account the OS-specific path separator, meaning that they
won't behave as intended on Windows.
For example, Dir is supposed to return all but the last element of the
path. For the path "C:\some\dir\somewhere", it is supposed to return
"C:\some\dir\", however, it returns ".".
Instead of these functions, the ones in filepath should be used instead.
Kubernetes-commit: 856bb5c8f266f5276f1a576f47be622d7cb384e7
If, for whatever reason, the context was context.Background(), the additional
goroutine was started and then got stuck forever because
context.Background().Done() is a nil channel. Found when indirectly
instantiating a broadcaster with such a context:
found unexpected goroutines:
[Goroutine 9106 in state chan receive (nil chan), with k8s.io/kubernetes/vendor/k8s.io/client-go/tools/record.NewBroadcaster.func1 on top of the stack:
goroutine 9106 [chan receive (nil chan)]:
k8s.io/kubernetes/vendor/k8s.io/client-go/tools/record.NewBroadcaster.func1()
/home/prow/go/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/vendor/k8s.io/client-go/tools/record/event.go:206 +0x2c
created by k8s.io/kubernetes/vendor/k8s.io/client-go/tools/record.NewBroadcaster in goroutine 8957
/home/prow/go/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/vendor/k8s.io/client-go/tools/record/event.go:205 +0x1a5
This can be fixed by checking for a nil channel.
Another problem also gets addressed: if Shutdown was called without canceling
the context, the goroutine also didn't stop. Now it waits for the cancelation
context and thus terminates in both cases.
Kubernetes-commit: eed6e29a5b8cfaa20fbc426541d9c74105d430ee
until #115478(use streaming against the etcd storage)
is resolved the cacher need a way to disable the streaming.
Kubernetes-commit: 41e706600aea7468f486150d951d3b8948ce89d5
27a68aee3a4834 introduced context support. In order to use that
also with NewEventBroadcasterAdapter, a variant of the call is needed to allow
the caller to specify the context.
The `logcheck:context` comment ensures that code which is meant to be
contextual uses the new call.
Kubernetes-commit: f8e25eff926c640c86daa46222bfaf8d625e75d7
checkWatchListConsistencyIfRequested performs a data consistency check only when
the KUBE_WATCHLIST_INCONSISTENCY_DETECTOR environment variable was set during a binary startup.
The consistency check is meant to be enforced only in the CI, not in production.
The check ensures that data retrieved by the watch-list api call
is exactly the same as data received by the standard list api call.
Note that this function will panic when data inconsistency is detected.
This is intentional because we want to catch it in the CI.
Kubernetes-commit: b31e7793d0d873a71c90caf8455556aa905cf88d
