Writes to policy resources don't instantaneously take effect in admission. ValidatingAdmissionPolicy
integration tests determine that the policies under test have taken effect by adding a sentinel
policy rule and polling until that rule is applied to a request.
If the marker resource names are the same for each test case in a series of test cases, then
observing a policy's effect on a marker request only indicates that _any_ test policy is in effect,
but it's not necessarily the policy the current test case is waiting for. For example:
1. Test 1 creates a policy and binding.
2. The policy and binding are observed by the admission plugin and take effect.
3. Test 1 observes that a policy is in effect via marker requests.
4. Test 1 exercises the behavior under test and successfully deletes the policy and binding it
created.
5. Test 2 creates a policy and binding.
6. Test 2 observes that a policy is in effect via marker requests, but the policy in effect is still
the one created by Test 1.
7. Test 2 exercises the behavior under test, which fails because it was evaluated against Test 1's
policy.
Generating a per-policy name for the marker resource in each test resolves the timing issue. In the
example, step (6) will not proceed until the admission plugin has observed the policy and binding
created in (5).
This should fix the following test when running it with CRI-O:
```
[It] [sig-node] [Feature:SidecarContainers] [Serial] Containers
Lifecycle when A node running restartable init containers reboots should
restart the containers in right order with the proper phase after the
node reboot
```
The issue is that we have prefixed "unable to retrieve container logs
for …" outputs in the message to be parsed. We now skip that part and
leave the current behavior untouched.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
This change adds consistent validation for server side apply to prevent
new CustomResources from being creating while its
CustomResourceDefinition is in the terminating state.
This comes up periodically; bumping to v5 introduces issues with
replace operations in JSON patches. k/k relies on non-RFC-compliant
operations which v5 no longer allows.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
LoadTranslations gets called during the init phase:
0 0x0000000005926c56 in k8s.io/kubectl/pkg/util/i18n.LoadTranslations
at ./staging/src/k8s.io/kubectl/pkg/util/i18n/i18n.go:146
1 0x0000000005926727 in k8s.io/kubectl/pkg/util/i18n.init.func1
at ./staging/src/k8s.io/kubectl/pkg/util/i18n/i18n.go:60
2 0x000000000592780f in k8s.io/kubectl/pkg/util/i18n.lazyLoadTranslations.func1
at ./staging/src/k8s.io/kubectl/pkg/util/i18n/i18n.go:191
3 0x0000000001b876e8 in sync.(*Once).doSlow
at /nvme/gopath/go-1.24.0/src/sync/once.go:78
4 0x0000000001b8753e in sync.(*Once).Do
at /nvme/gopath/go-1.24.0/src/sync/once.go:69
5 0x0000000005927565 in k8s.io/kubectl/pkg/util/i18n.lazyLoadTranslations
at ./staging/src/k8s.io/kubectl/pkg/util/i18n/i18n.go:187
6 0x00000000059275cd in k8s.io/kubectl/pkg/util/i18n.T
at ./staging/src/k8s.io/kubectl/pkg/util/i18n/i18n.go:201
7 0x000000000599fb6d in k8s.io/kubectl/pkg/cmd/apiresources.init
at <autogenerated>:1
8 0x0000000001b41bf4 in runtime.doInit1
at /nvme/gopath/go-1.24.0/src/runtime/proc.go:7350
9 0x0000000001b6bf8a in runtime.doInit
at /nvme/gopath/go-1.24.0/src/runtime/proc.go:7317
10 0x0000000001b33910 in runtime.main
at /nvme/gopath/go-1.24.0/src/runtime/proc.go:254
11 0x0000000001b72881 in runtime.goexit
at /nvme/gopath/go-1.24.0/src/runtime/asm_amd64.s:1700
During init, klog verbosity is either zero (making the log call redundant
because it doesn't print anything) or some other init function reconfigures
logging, in which case the output is potentially confusing because it is not
guaranteed that logging is reconfigured before the log call is invoked.
In other scenarios, flag parsing might switch from klog text format to
something else entirely, which then leads to a mixture of text and e.g. JSON
output. In general, code running during init should not log.
Using the same socket path for different test cases caused
test failure on windows:
listen unix C:\Users\azureuser\AppData\Local\Temp\TestRegistrationHandler3881105518\001/dra-plugin-a.sock:
bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
Creating unique socket path for every test case should fix it.
