For some reason the CI didn't fail when we open the PR. But when you run
"go test" as root, with all the capabilities, tests that exercise
permission errors will never work. As the capabilities makes them always
bypass the permission checks.
For some reason it seems that:
* Not all our CI was run when the PR was open
* The CI was changed to run as root now
* _Some_ CI was added and it runs as root
If it wasn't one of that, or a combination, I don't see how this could
have happened. If any of that indeed happened, it can break more tests
outside the userns package too.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
The idempotency.go (perhaps not so accurately named) contains
API calls that kubeadm does against an API server using client-go.
Some users seem to have unstable setups where for unknown reasons
the API server can be unavailable or refuse to respond as expected.
Use PollUntilContextTimeout in all exported functions to ensure
such API calls are all retry-able.
NOTE: The context passed to PollUntilContextTimeout is not propagated
in the polled function. Instead the poll function creates it's own
context 'ctx := context.Background()', this is to avoid
breaking expectations on the side of the callers, that expect
a certain type of error and not "context timeout" errors.
Additional changes:
- Make all context.TODO() -> context.Background()
- Update all unit tests and make sure during testing the retry
interval and timeout are short. Test coverage of idempotency.go
is at ~97%.
- Remove the TestMutateConfigMapWithConflict test. It does not
contribute much, because conflict handling is done at the API,
server side, not on the side of kubeadm. This simulating this is not
needed.
so the CRI runtime can report what features are supported by each
handler.
It is currently used to report support for the user namespace.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
This handler allows running execution prior to actual serving in a separate
goroutine when serving requests. Doing so benefits cases in serving long running
requests because it allows freeing memory used by the separate goroutine
and keeps the serving routines slim.
Signed-off-by: Eric Lin <exlin@google.com>
The pull-kubernetes-verify job is using this to run the base
verify-golangci.sh only in the pull-kubernetes-verify-lint job.
Because the file name was not quite right, it still ran.
We enabled topology hint on one of our services and this log line was
emitted ~92 million times in one day from one cluster tripping our log
quota for that cluster, as it is the log line cannot be disabled via the
`-v` flag because it does not specify verbosity.
I think more log locations need to set verbosity at which they are
logged, but this one is currently hurting the most.
