Change:
Lets put a metrics CI job in place that isnt . Investigate our test coverage of metrics-server See why our CI jobs dont test metrics-server Confirm that we are doing enough in is a good test, lets make it part of all our containerd jobs by removing the Serial tags
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions 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
/sig windows
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue 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
/assign
while were at it make that iterations a non-magic number
while were at it make sure the metrics stats are non-zero , so that we catch regressions turns out we DO run SERIAL jobs in the sig-windows dashboard either we dont collect enough metrics, so the tests pass, or we do, and we dont watch the dashboards :) https://k8s- <-- check the sig-windows dashboard...
this test starts 10 pods on a node at once and run into issues starting 10 pods on a single node when this was run in parallel with other jobs. Maybe we should consider adding a different metrics job that just starts 1-3 pods and does deeper validation of the metrics retruned?
Hey, is this issue still open? I would like to work on this, I am new to open source
We cannot de-serialize the existing metrics job due to its nature. We can however create new test cases that do not need to be run in parallel and do deeper validation of metrics like Jay suggested above. I'm not sure if is still working on the issue. If not feel free to work on this. Thanks!
/unassign
/retitle Add non-serialized metrics tests for Windows
do we have to make an another var _ with [Serial] not included in it and run 3 pods instead of 10 in it. Help needed, am I thinking correct here.

Discussion:
) var _ = SIGDescribe("[Feature:Windows] Kubelet-Stats [Serial]", func() { <del> f := framework.NewDefaultFramework("kubelet-stats-test-windows") </del> <ins> f := framework.NewDefaultFramework("kubelet-stats-test-windows-serial") </ins> ginkgo.Describe("Kubelet stats collection for Windows nodes", func() { ginkgo.Context("when running 10 pods", func() {

}) }) }) <ins> var _ = SIGDescribe("[Feature:Windows] Kubelet-Stats", func() { f := framework.NewDefaultFramework("kubelet-stats-test-windows") ginkgo.Describe("Kubelet stats collection for Windows nodes", func() { ginkgo.Context("when running 3 pods", func() { // 10 seconds is the default scrape timeout for metrics-server and kube-prometheus ginkgo.It("should return within 10 seconds", func() { ginkgo.By("Selecting a Windows node") targetNode, err := findWindowsNode(f) framework.ExpectNoError(err, "Error finding Windows node") framework.Logf("Using node: %v", targetNode.Name) ginkgo.By("Scheduling 3 pods") powershellImage := imageutils.GetConfig(imageutils.BusyBox) pods := newKubeletStatsTestPods(3, powershellImage, targetNode.Name) f.PodClient().CreateBatch(pods) ginkgo.By("Waiting up to 3 minutes for pods to be running") timeout := 3 * time.Minute e2epod.WaitForPodsRunningReady(f.ClientSet, f.Namespace.Name, 3, 0, timeout, make(map[string]string)) ginkgo.By("Getting kubelet stats 1 time") iterations := 1 var totalDurationMs int64 for i := 0; i < iterations; i++ { start := time.Now() nodeStats, err := e2ekubelet.GetStatsSummary(f.ClientSet, targetNode.Name) duration := time.Since(start) totalDurationMs += duration.Milliseconds() framework.ExpectNoError(err, "Error getting kubelet stats") // Perform some basic sanity checks on retrieved stats for pods in this test's namespace statsChecked := 0 for _, podStats := range nodeStats.Pods { if podStats.PodRef.Namespace != f.Namespace.Name { continue } statsChecked = statsChecked + 1 framework.ExpectEqual(*podStats.CPU.UsageCoreNanoSeconds > 0, true, "Pod stats should not report 0 cpu usage") framework.ExpectEqual(*podStats.Memory.WorkingSetBytes > 0, true, "Pod stats should not report 0 bytes for memory working set ") for _, containerStats := range podStats.Containers { framework.ExpectEqual(containerStats.Logs != nil, true, "Pod stats should have container log stats") framework.ExpectEqual(*containerStats.Logs.AvailableBytes > 0, true, "container log stats should not report 0 bytes for AvailableBytes") } } framework.ExpectEqual(statsChecked, 3, "Should find stats for 10 pods in kubelet stats") time.Sleep(5 * time.Second) } avgDurationMs := totalDurationMs / int64(iterations) durationMatch := avgDurationMs <= time.Duration(10*time.Second).Milliseconds() framework.Logf("Getting kubelet stats for node %v took an average of %v milliseconds over %v iterations", targetNode.Name, avgDurationMs, iterations) framework.ExpectEqual(durationMatch, true, "Collecting kubelet stats should not take longer than 10 seconds") }) }) }) }) </ins> // findWindowsNode finds a Windows node that is Ready and Schedulable func findWindowsNode(f *framework.Framework) (v1.Node, error) {