jiebi/CodeConvo huggingface dataset:
Code change:
N/A [sig-node] NodeProblemDetector: N/A https://prow- Not cgroupv2 compatible when access cpu and memory data
/sig node
Hi, can i work on this ?
Sure. Thanks
/assign
/triage accepted
/priority important-soon
/cc
are you still working on this? Were you able to setup environment to repro the test failure? Let us know if you need any help. Thanks!
Sorry for the delay, I followed the wrong guide and ended up getting stuck. But now I have managed to set it up. Please give me few more days to work on it.
Thanks Feel free to reach out here or on slack if you need any help, thanks for working on this!
/retitle Make nodeproblemdetector test cgroupv2 compatible
Failing job:
Testgrid:

Related discussion:
text: memoryUsage, err := strconv.ParseFloat(lines[0], 64) framework.ExpectNoError(err) <ins> var rssToken, inactiveFileToken string if isCgroupV2 { // Use Anon memory for RSS as cAdvisor on cgroupv2 // see https://github.com/google/cadvisor/blob/a9858972e75642c2b1914c8d5428e33e6392c08a/container/libcontainer/handler.go#L799 rssToken = "anon" inactiveFileToken = "inactive_file" } else { rssToken = "total_rss" inactiveFileToken = "total_inactive_file" } </ins> var totalInactiveFile float64 for _, line := range lines[1:] { tokens := strings.Split(line, " ") <del> if tokens[0] == "total_rss" { </del> <ins> if tokens[0] == rssToken { </ins> rss, err = strconv.ParseFloat(tokens[1], 64) framework.ExpectNoError(err) } <del> if tokens[0] == "total_inactive_file" { </del> <ins> if tokens[0] == inactiveFileToken { </ins> totalInactiveFile, err = strconv.ParseFloat(tokens[1], 64) framework.ExpectNoError(err) }
Code change:
N/A [sig-node] NodeProblemDetector: N/A https://prow- Not cgroupv2 compatible when access cpu and memory data
/sig node
Hi, can i work on this ?
Sure. Thanks
/assign
/triage accepted
/priority important-soon
/cc
are you still working on this? Were you able to setup environment to repro the test failure? Let us know if you need any help. Thanks!
Sorry for the delay, I followed the wrong guide and ended up getting stuck. But now I have managed to set it up. Please give me few more days to work on it.
Thanks Feel free to reach out here or on slack if you need any help, thanks for working on this!
/retitle Make nodeproblemdetector test cgroupv2 compatible
Failing job:
Testgrid:

Related discussion:
text: } func getCPUStat(f *framework.Framework, host string) (usage, uptime float64) { <del> cpuCmd := "cat /sys/fs/cgroup/cpu/system.slice/node-problem-detector.service/cpuacct.usage && cat /proc/uptime | awk '{print $1}'" </del> <ins> var cpuCmd string if isHostRunningCgroupV2(f, host) { cpuCmd = " cat /sys/fs/cgroup/cpu.stat | grep 'usage_usec' | sed 's/[^0-9]*//g' && cat /proc/uptime | awk '{print $1}'" } else { cpuCmd = "cat /sys/fs/cgroup/cpu/system.slice/node-problem-detector.service/cpuacct.usage && cat /proc/uptime | awk '{print $1}'" } </ins> result, err := e2essh.SSH(cpuCmd, host, framework.TestContext.Provider) framework.ExpectNoError(err) framework.ExpectEqual(result.Code, 0)
Code change:
N/A [sig-node] NodeProblemDetector: N/A https://prow- Not cgroupv2 compatible when access cpu and memory data
/sig node
Hi, can i work on this ?
Sure. Thanks
/assign
/triage accepted
/priority important-soon
/cc
are you still working on this? Were you able to setup environment to repro the test failure? Let us know if you need any help. Thanks!
Sorry for the delay, I followed the wrong guide and ended up getting stuck. But now I have managed to set it up. Please give me few more days to work on it.
Thanks Feel free to reach out here or on slack if you need any help, thanks for working on this!
/retitle Make nodeproblemdetector test cgroupv2 compatible
Failing job:
Testgrid:

Related discussion:
text: return } <ins> func isHostRunningCgroupV2(f *framework.Framework, host string) bool { result, err := e2essh.SSH("stat -fc %T /sys/fs/cgroup/", host, framework.TestContext.Provider) framework.ExpectNoError(err) framework.ExpectEqual(result.Code, 0) // 0x63677270 == CGROUP2_SUPER_MAGIC // https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html return strings.Contains(result.Stdout, "cgroup2") || strings.Contains(result.Stdout, "0x63677270") } </ins> func getNpdPodStat(f *framework.Framework, nodeName string) (cpuUsage, rss, workingSet float64) { summary, err := e2ekubelet.GetStatsSummary(f.ClientSet, nodeName) framework.ExpectNoError(err)
Code change:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --ci-cos-cgroupv2-containerd-node-e2e <!-- You can identify the SIG from the "prowjobconfigurl" on the testgrid dashboard for a test --<!-- Please see the deflaking doc () for more guidance! --/sig node
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : #### Which jobs are flaking: links to appreciated links to specific failures in spyglass appreciated </details
On cgroupv2, it looks like like the number of for cgroup is sometimes higher than is currently expected in the test. We currently expect this however, in a few runs of the test we've seen We may need to adjust this value similar as was done in for
/cc
yes, good idea. I think we need to adjust the PageFaults test as well. I've opened a PR:
/assign /triage accepted /area test /priority important-soon

Related discussion:
text: "UserDefinedMetrics": gomega.BeEmpty(), }) } <ins> expectedPageFaultsUpperBound := 1000000 </ins> expectedMajorPageFaultsUpperBound := 10 if IsCgroup2UnifiedMode() { <del> expectedMajorPageFaultsUpperBound = 1000 </del> <ins> // On cgroupv2 these stats are recursive, so make sure they are at least like the value set // above for the container. expectedPageFaultsUpperBound = 1e9 expectedMajorPageFaultsUpperBound = 100000 </ins> } podsContExpectations := sysContExpectations().(*gstruct.FieldsMatcher)
Code change:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --ci-cos-cgroupv2-containerd-node-e2e <!-- You can identify the SIG from the "prowjobconfigurl" on the testgrid dashboard for a test --<!-- Please see the deflaking doc () for more guidance! --/sig node
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : #### Which jobs are flaking: links to appreciated links to specific failures in spyglass appreciated </details
On cgroupv2, it looks like like the number of for cgroup is sometimes higher than is currently expected in the test. We currently expect this however, in a few runs of the test we've seen We may need to adjust this value similar as was done in for
/cc
yes, good idea. I think we need to adjust the PageFaults test as well. I've opened a PR:
/assign /triage accepted /area test /priority important-soon

Related discussion:
text: "UsageBytes":      bounded(10*e2evolume.Kb, memoryLimit), "WorkingSetBytes": bounded(10*e2evolume.Kb, memoryLimit), "RSSBytes":        bounded(1*e2evolume.Kb, memoryLimit), <del> "PageFaults":      bounded(0, 1000000), </del> <ins> "PageFaults":      bounded(0, expectedPageFaultsUpperBound), </ins> "MajorPageFaults": bounded(0, expectedMajorPageFaultsUpperBound), }) runtimeContExpectations := sysContExpectations().(*gstruct.FieldsMatcher)
Code change:
pull-kubernetes-unit TestUpdatePodWithTerminatedPod 10/8 (when it was introduced in ) No response No response Running with shows immediate failures: /sig node
/cc
/assign I will try to fix this. At present, I found that adding before the status check will definitely trigger the error
Looks like it stopped flaking? Was this fixed? /triage accepted
If the test runs fast enough, it won't failed but it's not guaranteed. fixed in
It's still flaking
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
this started flaking more on 3/21 - adding to the milestone for investigation to make sure something didn't regress here
cc
/unassign /assign

Related discussion:
text: func TestUpdatePodWithTerminatedPod(t *testing.T) { podWorkers, _ := createPodWorkers() terminatedPod := newPodWithPhase("0000-0000-0000", "done-pod", v1.PodSucceeded) <del> runningPod := &kubecontainer.Pod{ID: "0000-0000-0001", Name: "done-pod"} </del> <ins> orphanedPod := &kubecontainer.Pod{ID: "0000-0000-0001", Name: "orphaned-pod"} </ins> pod := newPod("0000-0000-0002", "running-pod") podWorkers.UpdatePod(UpdatePodOptions{
Code change:
pull-kubernetes-unit TestUpdatePodWithTerminatedPod 10/8 (when it was introduced in ) No response No response Running with shows immediate failures: /sig node
/cc
/assign I will try to fix this. At present, I found that adding before the status check will definitely trigger the error
Looks like it stopped flaking? Was this fixed? /triage accepted
If the test runs fast enough, it won't failed but it's not guaranteed. fixed in
It's still flaking
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
this started flaking more on 3/21 - adding to the milestone for investigation to make sure something didn't regress here
cc
/unassign /assign

Related discussion:
text: }) podWorkers.UpdatePod(UpdatePodOptions{ UpdateType: kubetypes.SyncPodKill, <del> RunningPod: runningPod, </del> <ins> RunningPod: orphanedPod, </ins> }) <ins> drainAllWorkers(podWorkers) </ins> if podWorkers.IsPodKnownTerminated(pod.UID) == true { t.Errorf("podWorker state should not be terminated") } if podWorkers.IsPodKnownTerminated(terminatedPod.UID) == false { t.Errorf("podWorker state should be terminated") } <del> if podWorkers.IsPodKnownTerminated(runningPod.ID) == true { t.Errorf("podWorker state should not be marked terminated for a running pod") </del> <ins> if podWorkers.IsPodKnownTerminated(orphanedPod.ID) == false { t.Errorf("podWorker state should be terminated for orphaned pod") </ins> } }
Code change:
As per the PRs kubernetes/kubernetes kubernetes/kubernetes, the defaulting behaviour of the pod exec parameters had been changed however in the code there is a comment where it is mentioned it defaults to True The comment about the default value must be removed and the openapi spec must be fixed Present in the file as comment and also in the OpenApiSpec swagger If this issue seems appropriate can I take it up please <details</details<details</details<details</details<details</details<details</details<details</details
/sig docs
/sig node
/assign
/assign
/help /triage accepted
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help /triage accepted </details
/kind documentation

Related discussion:
text: "uniqueItems": true }, { <del> "description": "Redirect the standard error stream of the pod for this call. Defaults to true.", </del> <ins> "description": "Redirect the standard error stream of the pod for this call.", </ins> "in": "query", "name": "stderr", "type": "boolean",
Code change:
As per the PRs kubernetes/kubernetes kubernetes/kubernetes, the defaulting behaviour of the pod exec parameters had been changed however in the code there is a comment where it is mentioned it defaults to True The comment about the default value must be removed and the openapi spec must be fixed Present in the file as comment and also in the OpenApiSpec swagger If this issue seems appropriate can I take it up please <details</details<details</details<details</details<details</details<details</details<details</details
/sig docs
/sig node
/assign
/assign
/help /triage accepted
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help /triage accepted </details
/kind documentation

Related discussion:
text: "uniqueItems": true }, { <del> "description": "Redirect the standard output stream of the pod for this call. Defaults to true.", </del> <ins> "description": "Redirect the standard output stream of the pod for this call.", </ins> "in": "query", "name": "stdout", "type": "boolean",
Code change:
As per the PRs kubernetes/kubernetes kubernetes/kubernetes, the defaulting behaviour of the pod exec parameters had been changed however in the code there is a comment where it is mentioned it defaults to True The comment about the default value must be removed and the openapi spec must be fixed Present in the file as comment and also in the OpenApiSpec swagger If this issue seems appropriate can I take it up please <details</details<details</details<details</details<details</details<details</details<details</details
/sig docs
/sig node
/assign
/assign
/help /triage accepted
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help /triage accepted </details
/kind documentation

Related discussion:
text: optional bool stdin = 1; // Redirect the standard output stream of the pod for this call. <del> // Defaults to true. </del> // +optional optional bool stdout = 2; // Redirect the standard error stream of the pod for this call. <del> // Defaults to true. </del> // +optional optional bool stderr = 3;
Code change:
As per the PRs kubernetes/kubernetes kubernetes/kubernetes, the defaulting behaviour of the pod exec parameters had been changed however in the code there is a comment where it is mentioned it defaults to True The comment about the default value must be removed and the openapi spec must be fixed Present in the file as comment and also in the OpenApiSpec swagger If this issue seems appropriate can I take it up please <details</details<details</details<details</details<details</details<details</details<details</details
/sig docs
/sig node
/assign
/assign
/help /triage accepted
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help /triage accepted </details
/kind documentation

Related discussion:
text: Stdin bool `json:"stdin,omitempty" protobuf:"varint,1,opt,name=stdin"` // Redirect the standard output stream of the pod for this call. <del> // Defaults to true. </del> // +optional Stdout bool `json:"stdout,omitempty" protobuf:"varint,2,opt,name=stdout"` // Redirect the standard error stream of the pod for this call. <del> // Defaults to true. </del> // +optional Stderr bool `json:"stderr,omitempty" protobuf:"varint,3,opt,name=stderr"`
Code change:
As per the PRs kubernetes/kubernetes kubernetes/kubernetes, the defaulting behaviour of the pod exec parameters had been changed however in the code there is a comment where it is mentioned it defaults to True The comment about the default value must be removed and the openapi spec must be fixed Present in the file as comment and also in the OpenApiSpec swagger If this issue seems appropriate can I take it up please <details</details<details</details<details</details<details</details<details</details<details</details
/sig docs
/sig node
/assign
/assign
/help /triage accepted
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help /triage accepted </details
/kind documentation

Related discussion:
text: var map_PodExecOptions = map[string]string{ "":          "PodExecOptions is the query options to a Pod's remote exec call.", "stdin":     "Redirect the standard input stream of the pod for this call. Defaults to false.", <del> "stdout":    "Redirect the standard output stream of the pod for this call. Defaults to true.", "stderr":    "Redirect the standard error stream of the pod for this call. Defaults to true.", </del> <ins> "stdout":    "Redirect the standard output stream of the pod for this call.", "stderr":    "Redirect the standard error stream of the pod for this call.", </ins> "tty":       "TTY if true indicates that a tty will be allocated for the exec call. Defaults to false.", "container": "Container in which to execute the command. Defaults to only container if there is only one container in the pod.", "command":   "Command is the remote command to execute. argv array. Not executed within a shell.",
Code change:
runs in a container. Talos sets OOM score to -450 for the kubelet container and passes in the kubelet config. End result is that OOM score adj is -999 though. should have configured OOM score . Source code analysis. First, OOM score is set correctly from the config (flags): But then, in container manager, OOM score is reset to -999 via the following: This function should skip action if the PID is not running on the host: But the function looks to be confusing: When kubelet runs in a container with PID namespace shared with the host, kubelet's PID namespace will be equal to PID 1 namespace. If kubelet runs in a container with unshared PID namespace, kubelet's PID is 1 and its PID namespace is identical to PID 1 namespace. So how this function can return ever? Moreover, function is always setting OOM score to a hardcoded constant -999 ignoring configuation (). No response <details, reproduced with 1.22. </details<details</details<details</details<details</details<details</details<details</details
/sig node
/triage accepted
/assign
I don't think this method needs to change... I have make a draft PR for the default value to use the flag if present, but I would like more time to add some testing. Maybe you can have a look: ?
Thanks, this PR looks good to me, as it's going to set the OOM score to the configured value. And in our case kubelet runs in a container (not on the host, with proper OOM score via OCI spec), so this code should be even skipped, not sure how this can be addressed.
neither do I...
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale

Related discussion:
text: RuntimeCgroupsName:    s.RuntimeCgroups, SystemCgroupsName:     s.SystemCgroups, KubeletCgroupsName:    s.KubeletCgroups, <ins> KubeletOOMScoreAdj:    s.OOMScoreAdj, </ins> CgroupsPerQOS:         s.CgroupsPerQOS, CgroupRoot:            s.CgroupRoot, CgroupDriver:          s.CgroupDriver,