Change:
// unschedulable, we need to wait until all of them are schedulable. framework.ExpectNoError(framework.WaitForAllNodesSchedulable(c, framework.TestContext.NodeSchedulableTimeout)) <ins> // If NumNodes is not specified then auto-detect how many are scheduleable and not tainted if framework.TestContext.CloudConfig.NumNodes == framework.DefaultNumNodes { framework.TestContext.CloudConfig.NumNodes = len(framework.GetReadySchedulableNodesOrDie(c).Items) } </ins> // Ensure all pods are running and ready before starting tests (otherwise, // cluster infrastructure pods that are being pulled or started can block // test pods from running, and tests that ensure all pods are running and

Discussion:
A) seems to be required by some tests. we need to decide if jobs need to pass explicitly or let the e2e framework detect how many worker nodes a cluster has. the conformance image has no notion of yet. B) the conformance image runs tests even in parallel mode: if "y" is set in the YAML for if we assume that tests should not run in parallel mode, this means we need to pass from the runner. C) should we switch the conformance image to ? currently it's . we need to check if this breaks anything. discussion: /area test /kind design /kind bug /assign
/sig testing
PRs - disable Parallel mode for conformance image (and test):
RE: the introduction of ` in this test broke not only the kubeadm tests but also the conformance image and sonobuoy. previously they did not require and we are now forced to detect the number of nodes outside of the e2e testing framework. possibly this test was the first conformance test that uses as a aggressive failure condition. there are two options here: A) adapt all prow jobs, conformance image and sonobuoy, etc to explicitly pass . this ensures that future test will rely on the number the user provides and expects. we already started going this route by providing mechanics for detecting schedulable nodes, per-solution. B) auto-detect "ready", schedulable nodes in the e2e framework as a start number before, say a daemon set test runs and compare outcomes. this way a test will run on whatever number of nodes are currently available. cc
/area conformance /milestone v1.14
Line should be a explicit failure, not a
i like option B!
related to
Note that this test was NOT new, the other bug is ignoring skipped conformance tests. Ideally that shouldn't be possible.
/assign
GitHub didn't allow me to assign the following users: johnSchnake, stevesloka. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available .

If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I'm reluctant to make a sweeping change for 1.14 other then a band aide inside of test-infra. Ideally I'd like to assign this issue to the test-commons group to solve in 1.15. Thoughts?
Agree that (A) (passing num-nodes explicitly) isnt a good option since it breaks other users who dont know about it in the first place and that this is well within the capabilities of the framework. So for option (B) during startup of the framework we need to grab the nodes and count the number that are schedulable and not tainted as master nodes, correct? Save that into a TestContext variable and then reference it elsewhere as needed? Is the plan to reuse the existing value? I'm not at this time familiar with that value and whether it is needed in some other capacity and shouldn't be auto-set. w.r.t. 1.14 vs 1.15; I don't have too strong a preference. I do generally prefer to let things bake a little longer inside of a release but it seems like if just the node count solves the problem its a small, scoped change that could make it in.
From slack: If num-nodes is not specified query on startup and over-ride the test context variable.
a control plane node can be tainted as "master", but still allow workloads. search for on all nodes, and exclude those that have it from the count. this is fed the flag, which is -1 by default. if the user didn't add a value my suggestion is to just update with the detected count. also possibly add notes about that in the flag description. future tests might decide to use this again (we already have some) and it will break if the user doesn't pass a valid number from the CLI flag. the "auto-detect if -1" logic seems reasonable and backwards compatible. how well our detection will work in complicated taint / toleration scenarios is another question. "Code Thaw" starts on the 19th of march. if we merge a change in master before that the change will also be picked by 1.14. if we patch this later the change has to be cherry picked for 1.14.