* cache: do not allocate chan for nothing
The explicit purpose of this channel is to never be closed and nothing
to be sent down on it. Hence, there's no need to allocate a channel - a
nil channel has exactly the desired behaviour.
Additionally, this is more relevant now that testing/synctest gets
unhappy when goroutines are blocked on reading on channels which are
created outside of the synctest bubble. Since this is a package var, that's
hard to avoid when using this package. Synctest is fine with nil
channels though.
Reported-by: Jussi Maki <jussi@isovalent.com>
Signed-off-by: David Bimmler <david.bimmler@isovalent.com>
* handlers: do not allocate chan for nothing
Nil chan has the desired semantics already, and this breaks
testing/synctest because the channel is allocated outside of the bubble.
Signed-off-by: David Bimmler <david.bimmler@isovalent.com>
---------
Signed-off-by: David Bimmler <david.bimmler@isovalent.com>
Kubernetes-commit: 52b7d035f9655d0c6ebeaaafd60add99700bb468
The net/http transport checks for immediate response when
its handling context cancellation. The unit test was racing
with this check by responding too fast.
Signed-off-by: Stanislav Láznička <slznika@microsoft.com>
Kubernetes-commit: efcf97f98c7c9891015d4f2b37d2fc3afcdd336c
Authorization, token authentication, imagepolicy admission, and audit webhooks configure RESTClients
that encode to JSON regardless of the ContentType of the provided rest.Config. Because this is
opaque to the RESTClient, configuring a ContentType other than "application/json" results in
requests with JSON-encoded bodies and a non-JSON media type in the Content-Type header. Webhook
servers that respect the Content-Type request header will be unable to decode an object from the
request body.
Explicitly overriding the ContentType of the provided rest.Config fixes this issue and is consistent
with how clients are constructed for conversion and admission webhooks.
Kubernetes-commit: ed07efbc57939afdf154afa80be35507d0a81d66
This brings a few fixes, drops github.com/pkg/errors (as a direct
dependency), and bumps many transitive dependencies. The
go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp bump to
v0.61.0 breaks "k8s.io/kubernetes/test/integration/apiserver: tracing"
consistently, so it's held back for now.
github.com/containerd/containerd/api pulls in gopkg.in/yaml.v3 so that
needs to be added to the exceptions in unwanted-dependencies.json.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
Kubernetes-commit: 684473af6232a5d68a5585837837d1a96f009414
The metrics assertion race with the metric update, and since this
happens at the serverside, we use an active look to check the metrics
instead of expecting to be updated immidiatly.
Change-Id: I9a64b66301d5f4ac3df0c0a01de10602a20f89ea
Kubernetes-commit: f07dcd443d7335d09dc0de7a47485e2e6c87d725
Test that assert on metrics use the returned status to sync the test, if
the metric is updated AFTER the state is returned the test will flake
because the assertion on the metric will race.
Change-Id: I317708a22cb47256c37dac3cab0463a2f925ad6b
Kubernetes-commit: 7ba22700bfd12cd32ff72db022e4b53ccda1deca
Reset metrics per status code also allow to log the particular status
code that flake, in case the problem comes from an specific one.
Change-Id: I29f67d4c5d76449350f45049f45ce8325a2d0ddd
Kubernetes-commit: 0aea6a1e45d178371b44eabcaf0d318a01f9ac3d