Patrick Ohly
Patrick Ohly
> Remaining culprits are feature_gate.go Addressed in https://github.com/kubernetes/kubernetes/pull/135432, commit included here only temporarily.
I support the proposal, but as SIG Testing TL I need to point out that this is not something that SIG Testing owns. The approval for this proposal probably falls...
So which SIG owns `hack/verify-featuregates.sh`? I'm just genuinely curious. In the end we will still need a volunteer to work on this, regardless of the SIG.
/test pull-kubernetes-e2e-kind-alpha-beta-features-race This should build with race detection (I temporarily included https://github.com/kubernetes/kubernetes/pull/133834) and this PR should detect the fake data races...
/test pull-kubernetes-e2e-kind-alpha-beta-features-race
/test pull-kubernetes-e2e-kind-alpha-beta-features-race Now with lower log verbosity.
The race detection does not work for the kubelet yet because retrieving that log is cluster provider dependent. It's probably worthwhile to support it for kind clusters, because in https://storage.googleapis.com/kubernetes-ci-logs/pr-logs/pull/133844/pull-kubernetes-e2e-kind-alpha-beta-features-race/1963169735218565120/artifacts/kind-worker/kubelet.log:...
> I think maybe we want to land the KEP before we get more of these "check after the entire test suite" invariant tests without having formalized what is permitted...
Perhaps log collection and analysis needs to run in parallel unconditionally and then the results only get reported as failures when the check is enabled?
/test pull-kubernetes-e2e-kind-alpha-beta-features-race