When a http2 connection dies due to ping timeout, http2 client gets an
error of "http2: client connection lost". This is similar to
ConnectionReset case so it should be retryable.
Signed-off-by: Eric Lin <exlin@google.com>
Kubernetes-commit: 2658a2b627f80ba46e81667278c884acee3988e9
This was making my eyes bleed as I read over code.
I used the following in vim. I made them up on the fly, but they seemed
to pass manual inspection.
:g/},\n\s*{$/s//}, {/
:w
:g/{$\n\s*{$/s//{{/
:w
:g/^\(\s*\)},\n\1},$/s//}},/
:w
:g/^\(\s*\)},$\n\1}$/s//}}/
:w
Kubernetes-commit: d55b67b349021b6c46fc6ce78f2a36bd4217145f
it is required for Server-SIde-Apply to function correctly (SSA is based on OpenAPI schemas)
Kubernetes-commit: 302daa889c5ddb9c862cd0101b94071e42a3081d
This touches cases where FromInt() is used on numeric constants, or
values which are already int32s, or int variables which are defined
close by and can be changed to int32s with little impact.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
Kubernetes-commit: 94410ee8078971b8894e5c400ce3fc79f02bc510
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.
Kubernetes-commit: 6db4cbfde7babfb34f5cd1059c769ec2d870f12a
* 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
Kubernetes-commit: eab66a687b282266f0520b79166f7f55828ffd28
waitUntilWatchCacheFreshAndForceAllEvents must be called without
a read lock held otherwise the watchcache won't be able to make
progress (i.e. the watchCache.processEvent method that requries acquiring an exclusive lock)
the deadlock can happen only when the alpha watchlist feature flag is on
and the client specifically requests streaming.
Kubernetes-commit: 476e407ffd2ab393840d3f7a9fd01b71698738a3
this check needs to go after any mutations. After the mutating admission chain, rest.BeforeUpdate (which is responsible for reverting updates to immutable timestamp fields, among other things.) is called in the store.Update function. Without moving this check, it will be possible for an object to be written to etcd with only a change to its managed fields timestamp.
Kubernetes-commit: 2b01f63b115e19e8ac9f8ee8e00dde65c5f40290
Fixes up a few misspellings of gorestful in the Director field docstring
for APIServerHandler.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
Kubernetes-commit: b1e3326eaeee982d3d5c1618022c306d50fe631e
Change admission ApplyTo() to take in clients instead of a rest.Config.
Signed-off-by: Andy Goldstein <andy.goldstein@redhat.com>
Kubernetes-commit: 364b66ddd6554a898724b6781fd90a15a38ddb41