Currently, watch package embeds context deadlineexceeded error
in it's own error using `%v`, as can be seen in here;
`fmt.Errorf("UntilWithSync: unable to sync caches: %v", ctx.Err())`
However, consumers of this function can not use
`errors.Is(err, context.DeadlineExceeded)` due this `%v`.
To let consumers can distinguish context deadlineexceeded errors,
this PR changes error embedding format to `%w`.
Kubernetes-commit: 6b7c365f8f6d50280c2dab171efdd4b93d964f32
Fake discovery should return an error if an error-returning reactor was prepended.
This is relevant e.g. for unit tests which test a function which relies
on discovery to check if an API Server is available.
Matches existing behavior of other fake types, for example fake_namespace.
Adds unit test coverage as well.
Kubernetes-commit: b47748103a53c0fe5ba1ddc950662ffc9bd9ed0f
Currently, when the remote connection is unexpected closed, forward() prints an error message saying "lost connection to pod" via runtime.HandleError, but then it returns nil for the error.
This prevents the caller from being able to handle this error differently.
This commit changes forward() to return the "lost connection to pod" error so that it can be handled by the caller.
Making this change enables kubectl port-forward to exit with code 1, instead of 0, which is the expected behavior for a command that has failed.
Kubernetes-commit: a9f04103854893056237a09250ad3335867b0391
When attempting to record a new Event and a new Serie on the apiserver
at the same time, the patch of the Serie might happen before the Event
is actually created. In that case, we handle the error and try to create
the Event. But the Event might be created during that period of time and
it is treated as an error today. So in order to handle that scenario, we
need to retry when a Create call for a Serie results in an AlreadyExist
error.
Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
Kubernetes-commit: 2f83117bcfe30ad3ada7f1ca66f4b885a1d5df25
There was a data race in the recordToSink function that caused changes
to the events cache to be overriden if events were emitted
simultaneously via Eventf calls.
The race lies in the fact that when recording an Event, there might be
multiple calls updating the cache simultaneously. The lock period is
optimized so that after updating the cache with the new Event, the lock
is unlocked until the Event is recorded on the apiserver side and then
the cache is locked again to be updated with the new value returned by
the apiserver.
The are a few problem with the approach:
1. If two identical Events are emitted successively the changes of the
second Event will override the first one. In code the following
happen:
1. Eventf(ev1)
2. Eventf(ev2)
3. Lock cache
4. Set cache[getKey(ev1)] = &ev1
5. Unlock cache
6. Lock cache
7. Update cache[getKey(ev2)] = &ev1 + Series{Count: 1}
8. Unlock cache
9. Start attempting to record the first event &ev1 on the apiserver side.
This can be mitigated by recording a copy of the Event stored in
cache instead of reusing the pointer from the cache.
2. When the Event has been recorded on the apiserver the cache is
updated again with the value of the Event returned by the server.
This update will override any changes made to the cache entry when
attempting to record the new Event since the cache was unlocked at
that time. This might lead to some inconsistencies when dealing with
EventSeries since the count may be overriden or the client might even
try to record the first isomorphic Event multiple time.
This could be mitigated with a lock that has a larger scope, but we
shouldn't want to reflect Event returned by the apiserver in the
cache in the first place since mutation could mess with the
aggregation by either allowing users to manipulate values to update
a different cache entry or even having two cache entries for the same
Events.
Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
Kubernetes-commit: 55ec09d377274b4a6107fe0b7a061ad408fe05a7
* Add tracker types and tests
* Modify ResourceEventHandler interface's OnAdd member
* Add additional ResourceEventHandlerDetailedFuncs struct
* Fix SharedInformer to let users track HasSynced for their handlers
* Fix in-tree controllers which weren't computing HasSynced correctly
* Deprecate the cache.Pop function
Kubernetes-commit: 8100efc7b3122ad119ee8fa4bbbedef3b90f2e0d
There should only be one source of truth for the API group's name and
version.
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
Kubernetes-commit: e13198ec6f52c4a6405388e90053954dc7656a31
Ginkgo v2.5.0 adds support for a "timeline": a full description of what happened
while a specific test ran, including failures, timeouts, and log output.
Ginkgo v2.6.0 adds ReportBeforeSuite which we need for
https://github.com/kubernetes/kubernetes/issues/114313.
Kubernetes-commit: f3ef4004317c1a12d84021be29dd5f92badc8eff
Update the definition of an isomorphic event in the events/v1 client to
match the aggregation logic that was already present in the core/v1
implementation.
The note field was omitted even though the message was used in the core
API aggregation because we didn't reach consensus.
Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
Kubernetes-commit: 21f2f746abc1a5a1b3193274401f5728e19cc26f
remove allowOmittingUsageKeyEncipherment as it is always true
Signed-off-by: Paco Xu <paco.xu@daocloud.io>
Kubernetes-commit: 160f015ef4affe903f98e74cf42b40fceef15cb9
The error result of `d.downloadAPIs()` is set in `aerr`,
not `err`.
This prevents a nil-ptr dereference of apiGroups in the next step.
Signed-off-by: Abhijit Hoskeri <abhijithoskeri@gmail.com>
Kubernetes-commit: 450ba4f50638ad9ee4d287a762a8530c64e89ebd
