If the cacher hasn't seen any event (when lastProcessedResourceVersion is zero) and
the bookmarkTimer has ticked then we shouldn't popExpiredWatchers. This is
because the watchers wont' be re-added and will miss future bookmark events when
the cacher finally receives an event via the c.incoming chan.
* cacher: remove locking from watcherBookmarkTimeBuckets
it turns out that the watcherBookmarkTimeBuckets
is called from only three places/methods: startDispatching, finishDispatching and Watch.
All these methods acquire c.Lock() before touching watcherBookmarkTimeBuckets.
Thus we could remove explicit locking in
watcherBookmarkTimeBuckets since the access is already synced.
* cacher: rename watcherBookmarkTimeBuckets methods to indicate that proper synchronisation must be used
testing.T.Cleanup ensures the environment is restored after a test and
any of its parallel sub-tests. It's possible that these can be
simplified further to T.Setenv(key, ""), but I did not investigate.
T.Setenv ensures that the environment is returned to its prior state
when the test ends. It also panics when called from a parallel test to
prevent racy test interdependencies.
T.Setenv ensures that the environment is returned to its prior state
when the test ends. It also panics when called from a parallel test to
prevent racy test interdependencies.
testing.T.Cleanup ensures the environment is restored after a test and
any of its parallel sub-tests. It's possible that some of these can be
simplified further to T.Setenv(key, ""), but I did not investigate.
T.Setenv ensures that the environment is returned to its prior state
when the test ends. It also panics when called from a parallel test to
prevent racy test interdependencies.
This allows us to return with a timeout error as soon as the
context is canceled. Previously in cases where the mount will
never succeed pods can get stuck deleting for 2 minutes.
In the Sync*Pod methods that call VolumeManager.WaitFor*, we
must filter out wait.Interrupted errors from being logged as
they are part of control flow, not runtime problems. Any
early interruption should result in exiting the Sync*Pod method
as quickly as possible without logging intermediate errors.
I contribute to SIG Node related topics since many releases, underlined
by recent enhancement graduations around SeccompDefault,
DownwardAPIHugePages, Kubelet Tracing and general long-term support for
features like seccomp or the CRI. This means that I think it's time to
get actively pulled into reviews, which is why I propose to become a
kubelet reviewer now.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
