mirror of
https://github.com/outbackdingo/kubernetes.git
synced 2026-02-18 00:40:32 +00:00
35c3a51e2c
Automatic merge from submit-queue (batch tested with PRs 49992, 48861, 49267, 49356, 49886) Correctly handle empty watch event cache Fixes https://github.com/kubernetes/kubernetes/issues/49956 Introduced byada60236f7which did not adjust the oldest available resourceVersion for an empty watch event cache. Exposed by74b9ba3b4d, which allowed controllers to get list results from etcd before the watch cache is ready (normally they list with resourceVersion=0 which serves the list request from the watch cache, blocking until it is ready) When the watch cache had an empty cache of watch events, it currently allows establishing a watch as if it can deliver a watch event for its currently synced resourceVersion. This results in an off-by-one error which can result in a missed watch event. Scenario: bob: 1. creates object at resourceVersion=11 sally: 1. does a list API request, gets a list resourceVersion of 10 (just before bob creates the object) 2. starts watch handled by watch cache at resourceVersion=10 Watch cache: 1. initial list gets resourceVersion=11, including the item created by bob 2. when determining the initial watch events to send to sally's watch, there are no watch events in the cache, so no initial watch events are sent. 3. the cache listerwatcher watches etcd starting at resourceVersion=11, so future events are fed into the event cache and to sally's watch The watch cache should have dropped sally's watch from resourceVersion=10 with a "gone" error, since it can't deliver the watch event for resourceVersion=11. This would force sally to relist (where she would get a list at resourceVersion=11) and rewatch (from resourceVersion=11) This particularly affects tests that create CRD/TPRs and establish watches on the new types as the storage layer's watch cache is also populating for that type. ```release-note Fix a bug in watch cache sometimes causing missing events after watch cache initialization. ```
This directory is the staging area for packages that have been split to their own repository. The content here will be periodically published to respective top-level k8s.io repositories.
The code in the staging/ directory is authoritative, i.e. the only copy of
the code. You can directly modify such code.
The vendor/k8s.io directory contains symlinks pointing to this staging area,
so to use a package in the staging area, you can import it as
k8s.io/<package-name>, as if the package were vendored. Packages will be
vendored from k8s.io/<package-name> for real after the test matrix is
converted to vendor k8s components.