For request like '/api/v1/watch/namespaces/*', don't set scope.namespace.
Because the func `addWatcher` add a watcher to allWatchers with the value `scope.namespace` not empty.
But the function `dispatchEvent` dispatch event with an empty namespace.
Signed-off-by: xyz-li <hui0787411@163.com>
Kubernetes-commit: 818fabe37b3fd7cebe36a43244120388977373cd
* apiserver/storage/continue: intro PrepareContinueToken
PrepareContinueToken prepares optional
parameters for retrieving additional results for a paginated request.
This function sets up parameters that a client can use to fetch the remaining results
from the server if they are available.
* apiserver/storage/etcd3: refactor to use PrepareContinueToken
Kubernetes-commit: efef32652af0af08a0b9c9bc547a4dce4a95f9f5
For case of SendInitialEvents, a buffer of objects is created. That
process takes a significant amount of memory and CPU when the resource
is of a large volume. Many objects may be not relevant when key is provided.
This commit applies key when composing the buffer for SendInitialEvents.
Signed-off-by: Eric Lin <exlin@google.com>
Kubernetes-commit: d9c6c8aa5047d724e0ebc8907f5fee4b10012ae3
The internal informer populates the RV as soon as it conducts
The first successful sync with the underlying store.
The cache must wait until this first sync is completed to be deemed ready.
Since we cannot send a bookmark when the lastProcessedResourceVersion is 0,
we poll aggressively for the first list RV before entering the dispatch loop.
Kubernetes-commit: a20abdb1f425b215ce969ef7114281741fce249d
The canonical import for json-patch v4 is
gopkg.in/evanphx/json-patch.v4 (see
https://github.com/evanphx/json-patch/blob/master/README.md#get-it for
reference).
Using the v4-specific path should also reduce the risk of unwanted v5
upgrade attempts, because they won't be offered as automated upgrades
by dependency upgrade management tools, and they won't happen through
indirect dependencies (see
https://github.com/kubernetes/kubernetes/pull/120327 for context).
Signed-off-by: Stephen Kitt <skitt@redhat.com>
Kubernetes-commit: 5300466a5c8988b479a151ceb77f49dd00065c83
There is no benefit of having RWMutex as we have one reader and multiple
writers. In such cases RWMutex has worse performance than Mutex.
Kubernetes-commit: 544ea424826ef60d703c5f4fb91b2c6a95f303aa
Signal is not needed as we never need to wake up when the waiting
is lowered, only when increased.
Kubernetes-commit: e6b54149bb42d58301e34872ebbcf2ea4bcfb474
Ticker behaves differently from what we want, we need a stable period
interval, but ticker doesn't provide that. From NewTicker docstring:
```
The ticker will adjust the time interval or drop ticks to make up for slow receivers.
```
Unfortunatelly there is no way to test it as the FakeClock doesn't
follow the real ticker behavior.
Kubernetes-commit: 7c0e9cda461e176959866b9c2d03b00e817e9b76
This is to mitigate CVE-2023-44487
until the Go standard library and golang.org/x/net
are fully fixed.
Signed-off-by: Jayapriya Pai <janantha@redhat.com>
Kubernetes-commit: e2503e50381cc9cc2e4a4c90f0738e54992558f8
This change makes us use the generic workqueue throughout the project in
order to improve type safety and readability of the code.
Kubernetes-commit: 6d0ac8c561a7ac66c21e4ee7bd1976c2ecedbf32
27a68aee3a4834 introduced context support for events. Creating an event
broadcaster with context makes tests more resilient against leaking goroutines
when that context gets canceled at the end of a test and enables per-test
output via ktesting.
The context could get passed to the constructor. A cleaner solution is to
enhance context support for the apiserver and then pass the context into the
controller's run method. This ripples up the call stack to all places which
start an apiserver.
Kubernetes-commit: b92273a760503cc57aba37c4d3a28554f7fec7f8
before:
go test -v -race -count 1 -run ^TestCacheWatcherDrainingNoBookmarkAfterResourceVersionReceived$
ok k8s.io/apiserver/pkg/storage/cacher 3.792s
after:
go test -v -race -count 1 -run ^TestCacheWatcherDrainingNoBookmarkAfterResourceVersionReceived$
ok k8s.io/apiserver/pkg/storage/cacher 1.783s
Kubernetes-commit: d21b86d53a3c4c42e41f8374e537c721251a00d2
The project does not recommend using insecure ports. Even
unauthenticated TLS is an improvement since it provides confidentiality.
If you relied upon this, please update to secure serving options.
Kubernetes-commit: de302c73e9558c192fde1cd7d6dcbea7eb76e950
since we don't provide compatibility guarantees for the storage
package it is okay to simply remove unused function.
Kubernetes-commit: a40f25f8e6516d1a59169cf88db8b3850a8c48c7
The code in ConvertToType checked for conversion into typeValue (=
"kubernetes.URL") instead of conversion into quantityTypeValue (=
"kubernetes.Quantity") and thus most likely failed with an incorrect "type
conversion error".
Kubernetes-commit: 02b4e99c9f0afa4ef9fa0283670c1515e40a5278
In contrast to the original HandleError and HandleCrash, the new
HandleErrorWithContext and HandleCrashWithContext functions properly do contextual
logging, so if a problem occurs while e.g. dealing with a certain request and
WithValues was used for that request, then the error log entry will also
contain information about it.
The output changes from unstructured to structured, which might be a breaking
change for users who grep for panics. Care was taken to format panics
as similar as possible to the original output.
For errors, a message string gets added. There was none before, which made it
impossible to find all error output coming from HandleError.
Keeping HandleError and HandleCrash around without deprecating while changing
the signature of callbacks is a compromise between not breaking existing code
and not adding too many special cases that need to be supported. There is some
code which uses PanicHandlers or ErrorHandlers, but less than code that uses
the Handle* calls.
In Kubernetes, we want to replace the calls. logcheck warns about them in code
which is supposed to be contextual. The steps towards that are:
- add TODO remarks as reminder (this commit)
- locally remove " TODO(pohly): " to enable the check with `//logcheck:context`,
merge fixes for linter warnings
- once there are none, remove the TODO to enable the check permanently
Kubernetes-commit: 5a130d2b71e5d70cfff15087f4d521c6b68fb01e
Currently type references for non-local names are output as relative
types which is subject to the resolution rules as defined at
https://protobuf.com/docs/language-spec#reference-resolution
This works fine within the k8s.io namespace where no subpackages are
named k8s, but other users of go-to-protobuf likely have k8s in their
package name. This causes conflicts in the search resolution when
executing `go-to-protobuf`:
```
company.example.com/k8s/custom/pkg/apis/custom.k8s.example.com/v1/generated.proto:64:12: "k8s.io.apimachinery.pkg.apis.meta.v1.ListMeta" is resolved to "company.example.com.k8s.custom.pkg.apis.custom.k8s.io.apimachinery.pkg.apis.meta.v1.ListMeta", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".k8s.io.apimachinery.pkg.apis.meta.v1.ListMeta") to start from the outermost scope.
```
To avoid this we can output fully qualified type references using a
preceding dot (.)
This results in a change for k8s generated.proto files, but the
effect is a noop.
Fixeskubernetes/code-generator#147
Signed-off-by: Andrew DeMaria <ademaria@cloudflare.com>
Kubernetes-commit: 9edf1fc51c56d565348c48f3765cf094518ba7ed
before:
go test -v -race -count 1 -run ^TestWatchNotHangingOnStartupFailure$
ok k8s.io/apiserver/pkg/storage/cacher 6.775s
after:
go test -v -race -count 1 -run ^TestWatchNotHangingOnStartupFailure$
ok k8s.io/apiserver/pkg/storage/cacher 2.781s
Kubernetes-commit: f5d945eb43c7bf8036a4bad8c22448e1146a7498
The individual cases can be safely run in parallel.
Before
go test -race -run TestWaitUntilWatchCacheFreshAndForceAllEvents
ok k8s.io/apiserver/pkg/storage/cacher 10.787s
After:
go test -race -run TestWaitUntilWatchCacheFreshAndForceAllEvents
ok k8s.io/apiserver/pkg/storage/cacher 4.857s
Kubernetes-commit: 3ecbb4dee00a5dd1e43e24a5952c2a90ef507ef1
It turns out that kube has a custom timeout for tests of 3 minutes.
The tests in the cacher package are utilizing nearly the
entire time and are being terminated, resulting in failing jobs.
Before the change, the TestWatchSemantics took ~43s to run. With this simple change, it now takes ~18s.
When we created the tests, we didn't measure the running time and assumed that waiting 1 second on a watch channel
to make sure no more events are received was sufficient.
This PR decreases the waiting time to 300 milliseconds.
Modern computers can perform many tasks within that time.
In addition to that, the tests are serial in nature, meaning that there is no other
actor that could add items to the database, which could result in receiving new items.
After the change the total running time decreased by 17%.
Before the tests needed ~176s after they need ~146s.
The changes also improved TestWatchSemanticInitialEventsExtended.
Kubernetes-commit: 5a74c8e2202044b664efce4be5d86d700e74506f
updates the test to wait 300 ms instead of 3s
the watch was established otherwise
we would be blocking on a call to cache.Watch(...)
in addition to that, the tests are serial in nature,
meaning that there is no other actor
that could add items to the database,
which could result in receiving new items.
Before:
go test -race -run TestEmptyWatchEventCache
ok k8s.io/apiserver/pkg/storage/cacher 8.450s
After:
go test -race -run TestEmptyWatchEventCache
ok k8s.io/apiserver/pkg/storage/cacher 2.635s
Kubernetes-commit: 926122c035a4f47a880db24d1a0be7ec129dd44d
Stop using defer as parallel subtest will might result in main test
finishing before subtest.
Fatal when same flag is set twice.
Kubernetes-commit: 9fcf279e2b91e7549190a433373f256fb5aebe85
Lukasz Szaszkiewicz