Change:
Release : v1.27 Testname: OpenAPI V3 Aggregated APIServer Description: Create an Aggregated APIServer. The OpenAPI V3 for the aggregated apiserver MUST be aggregated by the aggregator and published. The specification MUST be round trippable. <ins> This test case is marked as serial due to potential conflicts with other test cases that set up a sample-apiserver. For more information, see: https://github.com/kubernetes/kubernetes/issues/119582#issuecomment-2215054411. </ins> */ <del> ginkgo.It("should contain OpenAPI V3 for Aggregated APIServer", func(ctx context.Context) { </del> <ins> f.It("should contain OpenAPI V3 for Aggregated APIServer", f.WithSerial(), func(ctx context.Context) { </ins> config, err := framework.LoadConfig() framework.ExpectNoError(err) aggrclient, err := aggregatorclient.NewForConfig(config)

Discussion:
e2e conformance jobs, seen in aws, capz-windows, and kind seen back to 1.28 shows flakes going back as far as history exists No response [FAILED] could not find group version resource for dynamic client and wardle/flunders (discovery error: <nil, discovery results: map[schema.GroupVersionResource]struct {}{schema.GroupVersionResource{Group:"", Version:"v1", Resource:"bindings"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"configmaps"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"endpoints"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"events"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"limitranges"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"persistentvolumeclaims"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"pods"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"podtemplates"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"replicationcontrollers"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"resourcequotas"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"secrets"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"serviceaccounts"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"services"}:struct {}{}, schema.GroupVersionResource{Group:"apps", Version:"v1", Resource:"controllerrevisions"}:struct {}{}, schema.GroupVersionResource{Group:"apps", Version:"v1", Resource:"daemonsets"}:struct {}{}, schema.GroupVersionResource{Group:"apps", Version:"v1", Resource:"deployments"}:struct {}{}, schema.GroupVersionResource{Group:"apps", Version:"v1", Resource:"replicasets"}:struct {}{}, schema.GroupVersionResource{Group:"apps", Version:"v1", Resource:"statefulsets"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1",

Resource:"localsubjectaccessreviews"}:struct {}{}, schema.GroupVersionResource{Group:"autoscaling", Version:"v2", Resource:"horizontalpodautoscalers"}:struct {}{}, schema.GroupVersionResource{Group:"batch", Version:"v1", Resource:"cronjobs"}:struct {}{}, schema.GroupVersionResource{Group:"batch", Version:"v1", Resource:"jobs"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"leases"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"endpointslices"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"events"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"ingresses"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"networkpolicies"}:struct {}{}, schema.GroupVersionResource{Group:"policy", Version:"v1", Resource:"poddisruptionbudgets"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"rolebindings"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"roles"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"csistoragecapacities"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1beta1", Resource:"flunders"}:struct {}{}}) or - [FAILED] could not find group version resource for dynamic client and wardle/flunders (discovery error: unable to retrieve the complete list of server APIs: stale GroupVersion discovery: , discovery results: map[schema.GroupVersionResource]struct {}{schema.GroupVersionResource{Group:"", Version:"v1", Resource:"bindings"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"configmaps"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"endpoints"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"events"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"limitranges"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1",

Resource:"persistentvolumeclaims"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"pods"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"podtemplates"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"replicationcontrollers"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"resourcequotas"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"secrets"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"serviceaccounts"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"services"}:struct {}{}, schema.GroupVersionResource{Group:"apps", Version:"v1", Resource:"controllerrevisions"}:struct {}{}, schema.GroupVersionResource{Group:"apps", Version:"v1", Resource:"daemonsets"}:struct {}{}, schema.GroupVersionResource{Group:"apps", Version:"v1", Resource:"deployments"}:struct {}{}, schema.GroupVersionResource{Group:"apps", Version:"v1", Resource:"replicasets"}:struct {}{}, schema.GroupVersionResource{Group:"apps", Version:"v1", Resource:"statefulsets"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"localsubjectaccessreviews"}:struct {}{}, schema.GroupVersionResource{Group:"autoscaling", Version:"v2", Resource:"horizontalpodautoscalers"}:struct {}{}, schema.GroupVersionResource{Group:"batch", Version:"v1", Resource:"cronjobs"}:struct {}{}, schema.GroupVersionResource{Group:"batch", Version:"v1", Resource:"jobs"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"leases"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"endpointslices"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"events"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"ingresses"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"networkpolicies"}:struct {}{}, schema.

GroupVersionResource{Group:"policy", Version:"v1", Resource:"poddisruptionbudgets"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"rolebindings"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"roles"}:struct {}{}, schema.GroupVersionResource{Group:"", Version:"v1", Resource:"csistoragecapacities"}:struct {}{}}) Unclear if the issue is discovery going stale, or the aggregated server not responding, or something else /sig api-machinery
last flake on sig-release-master-blocking testgrid is 03-05 As it does not flake on the board anymore and still flake in other CIs, remove it from release signal board.
/assign Based on , I don't see it flaking as far as history exists. It seemed to have started flaking around March/April 2023. This also corresponds to when aggregated discovery was enabled by default so it may be related. Will do some more digging.
/triage accepted
Hey Is this issue fixed? If yes, from which version of kubernetes will this fix be available from?
This still flakes in some CIs. The flake rate is very low, but it is a conformance test.
Thanks for the quick response. I see it is very flaky. Is there any active work going on to fix this? If yes, is there any estimated time by which it could be fixed?
do you have some update on this?
cc.

I see the flake in recent run of later find it flake in as well. (not flake now) or More flakes can be found in /kind flake <!-- If this is a flake, please add: /kind flake --/sig api-machinery a slack thread a similar issue: for windows CI
/cc
Likely a test job misconfiguration. /assign /triage accepted
It seems there was a previous related issue
/cc
From Cloud provider testgrid is testing against master k8s branch, while the test requires a change in kube-aggregator, which is not yet cherry-picked to cloud provider testgrid release-1.28
It not only flakes on windows CI.
hit in
Flake in as well.
/remove-sig windows
Flake in .
See
/unassign
this test is still flaking but rarely? from a kind job today
This is still flaking, see a recent duplicate:
Hello! This Flake has not been updated for a long time, so I'd like to check what's the status. The code freeze is starting 02:00 UTC Wednesday 10th July 2024 (about 4 weeks from now), and while there is still plenty of time, we want to ensure that each PR has a chance to be merged on time. As this is tagged for 1.31, is it still planned for this release?
/milestone v1.31
It seems it is failing in
cc. Hit the same in the presubmit which ran against one of my PRs. Did some digging into this. It turned out to be a conflict between the following test cases running in parallel: [It] [sig-api-machinery] Aggregator Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] [It] [sig-api-machinery] OpenAPIV3 should contain OpenAPI V3 for Aggregated APIServer Both test cases call . As a result, two cluster-scoped s are created, one for and one for . The existence of the causes to fail, as it results in returning instead of the expected . I also managed to reproduce this issue with hydrophone: See for test logs. Finally, the solution is to mark both test cases as [Serial]. I'll submit a PR shortly for this.

/assign
can we avoid to make them serial? do we have a way to make two tests to not able to run at the same time?
the only way, currently, is to mark (at least) one as . I have plans (more of a long-term vision, really) for more but for now your best recourse is to use . I suppose you could also leverage Kubernetes and have both tests get/remove some sort of agreed upon mutex in the cluster and hang out and wait until the mutex is cleared before running. This would allow them to run in parallel with other specs but would force them to serialize wrt each other if they ever try to run concurrently. While doable, this will introduce a fair bit of complexity and a very different new internal contract into the test suite. It's Almost Certainly a Bad Idea.
I agree that marking the tests as serial is currently our best option. We talked about running all conformance tests with a single invocation. That can be done with without skipping the serial tests: Ginkgo will run non-serial tests in parallel and then the serial ones.
let's mark the non-conformance as serial then, Serial are skipped by default in a lot of places and missing coverage in a conformance test is something I would prefer to avoid