Change:
What happened: I am questioning validity of the test. Comments under of say: The test scenario described as it is sounds reasonable. The only nitpick I have is the very first sentence saying "". Pod's resource limits are ignored in predicates. They take effect in the scoring phase when priorities are computed. Also, priorities are computed only when there are at least two candidate nodes. So after revisiting the step number 5 it's impossible to make sure the additional pod does or does not get scheduled when setting the resource limits. There are either no candidate nodes or one. In which case the limits are ignored and the test passes in the first case and fails in the second. In case there are at least two candidate nodes, one of them will always get picked. In which case the additional pod gets scheduled (no matter what the resource limits field says). In the framework: resource limits are accessed through method [1] is used to perform pre-scoring [2] in the scoring phase score is computed through method [3] The test is alternating between passing and failing state. It passes when predicates give empty list of candidate nodes and failing when the list of candidate nodes is non-empty. Thus, making the pod resource limits ineffective. [1] [2] [3] What you expected to happen: Have another node schedule the additional pod validating that all saturated nodes (with scheduled) have lower score (0 in case of plugin). Or, invalidate the test by removing it. Can anyone check the test validity and confirm/disprove my statement about ineffectiveness of the resource limits? How to reproduce it (as minimally and precisely as possible): Make sure there is at least one node with non-zero free cpu resource before running the step 5. Anything else we need to know?: Environment: Kubernetes version (use ): master HEAD Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
cc
I have noticed you refactored the test in Can you still recall the original intent of the test? I can't grasp how the limits are actually taken into account.
I agree, I think the test is wrong, the scheduler doesn't make fit decisions on resource limits. In the test, should have set. do you mind fixing the test and update the test comment please?
On it /assign

Discussion:
import ( "fmt" <del> podutil "k8s.io/kubernetes/pkg/api/v1/pod" </del> "time" v1 "k8s.io/api/core/v1"

"k8s.io/apimachinery/pkg/util/uuid" utilversion "k8s.io/apimachinery/pkg/util/version" clientset "k8s.io/client-go/kubernetes" <ins> podutil "k8s.io/kubernetes/pkg/api/v1/pod" </ins> "k8s.io/kubernetes/test/e2e/framework" e2eevents "k8s.io/kubernetes/test/e2e/framework/events" e2ekubelet "k8s.io/kubernetes/test/e2e/framework/kubelet"

}) <del> // This test verifies we don't allow scheduling of pods in a way that sum of local ephemeral storage limits of pods is greater than machines capacity. </del> <ins> // This test verifies we don't allow scheduling of pods in a way that sum of local ephemeral storage resource requests of pods is greater than machines capacity. </ins> // It assumes that cluster add-on pods stay stable and cannot be run in parallel with any other test that touches Nodes or Pods. // It is so because we need to have precise control on what's running in the cluster. ginkgo.It("validates local ephemeral storage resource limits of pods that are allowed to run [Feature:LocalStorageCapacityIsolation]", func() {

Limits: v1.ResourceList{ v1.ResourceEphemeralStorage: *resource.NewQuantity(ephemeralStoragePerPod, "DecimalSI"), }, <ins> Requests: v1.ResourceList{ v1.ResourceEphemeralStorage: *resource.NewQuantity(ephemeralStoragePerPod, "DecimalSI"), }, </ins> }, } WaitForSchedulerAfterAction(f, createPausePodAction(f, conf), ns, podName, false)

}) // This test verifies we don't allow scheduling of pods in a way that sum of <del> // limits of pods is greater than machines capacity. </del> <ins> // resource requests of pods is greater than machines capacity. </ins> // It assumes that cluster add-on pods stay stable and cannot be run in parallel // with any other test that touches Nodes or Pods. // It is so because we need to have precise control on what's running in the cluster.

/* Release : v1.9 Testname: Scheduler, resource limits <del> Description: Scheduling Pods MUST fail if the resource limits exceed Machine capacity. </del> <ins> Description: Scheduling Pods MUST fail if the resource requests exceed Machine capacity. </ins> */ framework.ConformanceIt("validates resource limits of pods that are allowed to run ", func() { WaitForStableCluster(cs, masterNodes)

Limits: v1.ResourceList{ v1.ResourceCPU: *resource.NewMilliQuantity(nodeMaxAllocatable*5/10, "DecimalSI"), }, <ins> Requests: v1.ResourceList{ v1.ResourceCPU: *resource.NewMilliQuantity(nodeMaxAllocatable*5/10, "DecimalSI"), }, </ins> }, } WaitForSchedulerAfterAction(f, createPausePodAction(f, conf), ns, podName, false)