Change:
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

Discussion:
} } <ins> // SetUpSampleAPIServer sets up a sample-apiserver. // // Important: // Test cases that call this function should be marked as serial due to potential conflicts // with other test cases that also set up a sample-apiserver. For more information, see // https://github.com/kubernetes/kubernetes/issues/119582#issuecomment-2215054411. </ins> func SetUpSampleAPIServer(ctx context.Context, f *framework.Framework, aggrclient *aggregatorclient.Clientset, image string, n sampleAPIServerObjectNames, apiServiceGroupName, apiServiceVersion string) { ginkgo.By("Registering the sample API server.") client := f.ClientSet

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)