jiebi/CodeConvo huggingface dataset:
Change:
Corresponds to merge of /kind failing-test /sig node /assign /milestone v1.27 /priority critical-urgent === RUN TestSyncKnownPods WARNING: DATA RACE Write at 0x00c000906f60 by goroutine 1395: runtime.mapdeletefaststr() +0x0 (podWorkers).cleanupPodUpdates() +0x299 (podWorkers).completeTerminated() +0x1f4 (podWorkers).podWorkerLoop() +0x18b6 (podWorkers).UpdatePod.func1() +0x175 Previous read at 0x00c000906f60 by goroutine 1380: () +0x1056 testing.tRunner() +0x216 testing.(T).Run.func1() +0x47 Goroutine 1395 (running) created at: (podWorkers).UpdatePod() +0x5131 () +0xc4 testing.tRunner() +0x216 testing.(*T).Run.func1() +0x47
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
This is crazy hard to reproduce locally - I also don't think I saw it one time during development. It's definitely a race caused by my change, but I don't remember hitting it (I would have been hypersensitive to this test). That's concerning.
Rank 2nd for : " TestSyncKnownPods": 15,

Discussion:
// verify workers that are not terminated stay open even if config no longer // sees them podWorkers.SyncKnownPods(nil) <del> if len(podWorkers.podUpdates) != 2 { </del> <ins> drainAllWorkers(podWorkers) if len(podWorkers.podUpdates) != 0 { </ins> t.Errorf("Incorrect number of open channels %v", len(podWorkers.podUpdates)) } if len(podWorkers.podSyncStatuses) != 2 {
Change:
Must be a result of When running kubelet in standalone mode got this panic: No panic run kubelet in standalone mode No response master branch <detailsN/A </details<detailsN/A </details<details</details<details</details<details</details
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 node /sig storage /priority critical-urgent
/assign
I saw this as well. It is another instance of nil client pointer access.
Here's the old reconstruction logic with standalone kubelet handling:
Reading scattered docs, "standalone mode" is a kubelet without and it won't ever get any connection to the API server, right? Is there an e2e ~test~ job that runs kubelet in standalone mode?
Fix: I haven't found a presubmit job with a standalone kubelet.
I don't believe we have a presubmit for this (yet). I can repro this in local cluster with standalone kubelet with a small code change: I tried your diff and it works. Please feel free to try the above for double-verification.

Discussion:
func (rc *reconciler) updateReconstructedDevicePaths() { klog.V(4).InfoS("Updating reconstructed devicePaths") <ins> if rc.kubeClient == nil { // Skip reconstructing devicePath from node objects if kubelet is in standalone mode. // Such kubelet is not expected to mount any attachable volume or Secrets / ConfigMap. klog.V(2).InfoS("Skipped reconstruction of DevicePaths from node.status in standalone mode") rc.volumesNeedDevicePath = nil return } </ins> node, fetchErr := rc.kubeClient.CoreV1().Nodes().Get(context.TODO(), string(rc.nodeName), metav1.GetOptions{}) if fetchErr != nil { // This may repeat few times per second until kubelet is able to read its own status for the first time.
Change:
master-informing kubeadm-kinder-upgrade-1-26-latest kubeadm-kinder-latest 03-15 04:46 IST No response /sig api-machinery
this is a conformance test, so something has to happen with this specific environment, or it should be failing in all jobs The fact that the job name has upgrade in the name indicates that there can be some skew problem, which e2e test run this job and against which version?
Confirmed this is passing in other jobs This is related to this specific job
Can we add to the conformance test? I tried a fix like
/triage accepted

Discussion:
if err := verifyKubectlExplain(f.Namespace.Name, crd.Crd.Spec.Names.Plural+".spec", `(?s)DESCRIPTION:.*Specification of Foo.*FIELDS:.*bars.*<[]Object>.*List of Bars and their specs`); err != nil { framework.Failf("%v", err) } <del> if err := verifyKubectlExplain(f.Namespace.Name, crd.Crd.Spec.Names.Plural+".spec.bars", `(?s)FIELD:.*bars.*<[]Object>.*DESCRIPTION:.*List of Bars and their specs.*FIELDS:.*bazs.*<[]string>.*List of Bazs.*name.*<string>.*Name of Bar`); err != nil { </del> <ins> if err := verifyKubectlExplain(f.Namespace.Name, crd.Crd.Spec.Names.Plural+".spec.bars", `(?s)(FIELD|RESOURCE):.*bars.*<[]Object>.*DESCRIPTION:.*List of Bars and their specs.*FIELDS:.*bazs.*<[]string>.*List of Bazs.*name.*<string>.*Name of Bar`); err != nil { </ins> framework.Failf("%v", err) }
Change:
I noticed that kube-controller-manager is consuming visible amount of CPU in completely idle 5k node cluster (~7 cores/s) while for comparison kube-apiserver was using much less that time. I fetched pprof and noticed that we are burning significant in metrics.(attachDetachStateCollector).CollectWithStability:! Going further, most of the cpu is used for fmt.Errorf for formatting v1.Volume in line 160: which is never actually used by the caller We do not use significant cpu for preparing error messages that are then ignored. pprof cluster with some pods and volumes. No response_ <details26.1 </details<detailsgke, any? </details<details</details<details</details<details</details<details</details
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
A trivial fix would be actually to change GetInTreePluginNameFromSpec to write only PV/Volume names instead of entire specs in error message.
/assign In scheduler we use this function to check if we can translate the in-tree PV to CSI, I think we also only need the name of the pv. I'll create a pr for this one line change.
/sig storage Instrumentation ?

Discussion:
return curPlugin.GetInTreePluginName(), nil } } <del> return "", fmt.Errorf("could not find in-tree plugin name from persistent volume %v", pv) </del> <ins> return "", fmt.Errorf("could not find in-tree plugin name from persistent volume %s", pv.Name) </ins> } else if vol != nil { for _, curPlugin := range inTreePlugins { if curPlugin.CanSupportInline(vol) { return curPlugin.GetInTreePluginName(), nil } } <del> return "", fmt.Errorf("could not find in-tree plugin name from volume %v", vol) </del> <ins> return "", fmt.Errorf("could not find in-tree plugin name from volume %s", vol.Name) </ins> } else { return "", errors.New("both persistent volume and volume are nil") }

return csiDriverName, nil } } <del> return "", fmt.Errorf("could not find CSI Driver name for plugin %v", pluginName) </del> <ins> return "", fmt.Errorf("could not find CSI Driver name for plugin %s", pluginName) </ins> } // GetInTreeNameFromCSIName returns the name of the in-tree plugin superseded by

if plugin, ok := inTreePlugins[pluginName]; ok { return plugin.GetInTreePluginName(), nil } <del> return "", fmt.Errorf("could not find In-Tree driver name for CSI plugin %v", pluginName) </del> <ins> return "", fmt.Errorf("could not find In-Tree driver name for CSI plugin %s", pluginName) </ins> } // IsPVMigratable tests whether there is migration logic for the given Persistent Volume

if plugin, ok := inTreePlugins[driverName]; ok { return plugin.RepairVolumeHandle(volumeHandle, nodeID) } <del> return "", fmt.Errorf("could not find In-Tree driver name for CSI plugin %v", driverName) </del> <ins> return "", fmt.Errorf("could not find In-Tree driver name for CSI plugin %s", driverName) </ins> }
Change:
/kind cleanup /kind documentation /sig scheduling /sig node /sig apps The ownership of controller/nodelifecycle is unclear. The currently has some individual names and no labels, although it gets a sig/apps label from the parent pkg/controller OWNERS. This controller has the following functionality: Add taints based on health of the node (from conditions) Evict Pods based on NoExecute taints. The candidates for long term ownership are: : The ones who introduced it and overall maintain taints and tolerations. : Because it's called "node lifecycle", although this could be a misnomer. : Due to implications to the lifecycle of applications and because they are the main shepherds of kcm. I think it makes the most sense under scheduling, but wanted to gather all stakeholder's feedback.
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
cc
cc as original author
I think both scheduling and node can own it, if node is too overwhelmed, sig scheduling makes sense as a home.
Thanks, It would be nice to sort out the ownership. It sounds reasonable for sig-scheduling to own it. /cc
Outcome from SIG Scheduling meeting: As already identified, this controller actually has 2 functionalities. From a technical standpoint, the following ownership makes sense to SIG Scheduling leads: Setting taints based on Node conditions -SIG Node Evicting pods that don't tolerate NoExecute taints -SIG Scheduling This ownership structure can be set-up even before is implemented, as the taint functionality has its own folder. I'll create a PR based on the above. But and please raise any concerns.
+1 on this proposal.
+1 on the proposal - I believe if we were to assign responsibility to who owns node level invariants that apply to workloads, it would be sig-node (they generally own node + pod). pod-safety, for instance, I considered owned by sig-node even though it touches storage, apps, api-machinery, and scheduling because the node owns the pod at the time safety is imposed.

Discussion:
# See the OWNERS docs at https://go.k8s.io/owners approvers: <del> - bowei - k82cn </del> <ins> - sig-node-approvers </ins> reviewers: <del> - smarterclayton - ingvagabund - k82cn </del> <ins> - sig-node-reviewers </ins> emeritus_approvers: <ins> - bowei - k82cn </ins> - gmarek <ins> labels: - sig/node </ins>

<ins> # See the OWNERS docs at https://go.k8s.io/owners approvers: - sig-scheduling-maintainers reviewers: - sig-scheduling labels: - sig/scheduling </ins>
Change:
E2eNode Suite.[It] [sig-node] MirrorPodWithGracePeriod when create a mirror pod and the container runtime is temporarily down during pod termination [NodeConformance] [Serial] [Disruptive] the mirror pod should terminate successfully Perma failure here: E2eNode Suite.[It] [sig-node] MirrorPodWithGracePeriod when create a mirror pod and the container runtime is temporarily down during pod termination [NodeConformance] [Serial] [Disruptive] the mirror pod should terminate successfully E2eNode Suite.[It] [sig-node] MirrorPodWithGracePeriod when create a mirror pod and the container runtime is temporarily down during pod termination [NodeConformance] [Serial] [Disruptive] the mirror pod should terminate successfully Since it was created at No response No response /sig node
/cc
/cc /cc is there anything specific to CRI-O that will make test fail
/assign
The test fails there: Hm, scraping the kubelet logs it looks like that we miss a metric: cc
/triage accepted /priority important-soon seeing this in the wild
failed for this in as well
It seems to fail on on :
Having a fix in mind in

Discussion:
) func performContainerRuntimeUnitOp(op containerRuntimeUnitOp) error { <del> ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second) </del> <ins> ctx, cancel := context.WithTimeout(context.Background(), 2*time.Minute) </ins> defer cancel() conn, err := dbus.NewWithContext(ctx)

switch op { case startContainerRuntimeUnitOp: <del> conn.StartUnitContext(ctx, containerRuntimeUnitName, "replace", reschan) </del> <ins> _, err = conn.StartUnitContext(ctx, containerRuntimeUnitName, "replace", reschan) </ins> case stopContainerRuntimeUnitOp: <del> conn.StopUnitContext(ctx, containerRuntimeUnitName, "replace", reschan) </del> <ins> _, err = conn.StopUnitContext(ctx, containerRuntimeUnitName, "replace", reschan) </ins> default: framework.Failf("Unexpected container runtime op: %v", op) } <ins> framework.ExpectNoError(err, "dbus connection error") </ins> job := <-reschan framework.ExpectEqual(job, "done", "Expected job to complete with done")
Change:
Yesterday. No response /sig release /priority critical-urgent
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

Discussion:
} counter.Inc() <del> deprecatedCounter, err := deprecatedPodLogsUsage.GetMetricWithLabelValues(usageType) if err != nil { utilruntime.HandleError(err) return } deprecatedCounter.Inc() </del> <ins> deprecatedPodLogsUsage.WithLabelValues(usageType).Inc() </ins> } // NewGetOptions creates a new options object
Change:
Multiple jobs started to fail after the tag to 1.28.0-alpha.0 ! The reasons is that the apiserver is panicing when trying to access the pod logs, something very common in all e2e tests, see this occurrence per example The problem is caused by trying to update some metrics deprecated in 1.27 This change was introduced here I'm not very familiar with this subsystem, it seems that the logic to handle the deprecation in the metrics is not correct, as it is panicing when is accessed, or we should simple just not try to update them I really can't say what is the best course of action, we should not have anything in the codebase that modify the behavior depending on the external tags, but my feeling is we should not try to go for quick fix just to get the pipeline green. /priority critical-urgent /release blocking /sig instrumentation
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
/assign /cc
/milestone v1.27

Discussion:
} counter.Inc() <del> deprecatedCounter, err := deprecatedPodLogsUsage.GetMetricWithLabelValues(usageType) if err != nil { utilruntime.HandleError(err) return } deprecatedCounter.Inc() </del> <ins> deprecatedPodLogsUsage.WithLabelValues(usageType).Inc() </ins> } // NewGetOptions creates a new options object
Change:
Example failure - Serial node e2e tests This is new test introduced in v1.27 No response No response No response /sig node
It seems the issue is that a previous test that ran had a pod around which was not terminated, namely The test started around but (which was created by pod-conditions-test), was fully terminated only at which is after this test started: Due to the pod not being fully terminated when the test is being run, the metric assertions fail.
/triage accepted

Discussion:
"context" "fmt" "os" <ins> "strings" </ins> "time" "github.com/onsi/ginkgo/v2"

"k8s.io/apimachinery/pkg/util/uuid" clientset "k8s.io/client-go/kubernetes" "k8s.io/kubernetes/test/e2e/framework" <ins> e2epod "k8s.io/kubernetes/test/e2e/framework/pod" </ins> imageutils "k8s.io/kubernetes/test/utils/image" admissionapi "k8s.io/pod-security-admission/api" )

}) ginkgo.Context("and the container runtime is temporarily down during pod termination [NodeConformance] [Serial] [Disruptive]", func() { <ins> ginkgo.BeforeEach(func(ctx context.Context) { // Ensure that prior to the test starting, no other pods are running or in the process of being terminated other than the mirror pod. // This is necessary as the test verifies metrics that assume that there is only one pod (the static pod) being run, and all other pods have been terminated. gomega.Eventually(ctx, func(ctx context.Context) error { podList, err := e2epod.NewPodClient(f).List(ctx, metav1.ListOptions{}) if err != nil { return fmt.Errorf("failed listing pods while waiting for all pods to be terminated: %v", err) } var remainingPods []string for _, pod := range podList.Items { // The mirror pod is the only expected pod to be running if pod.Name == mirrorPodName && pod.Namespace == ns { continue } remainingPods = append(remainingPods, fmt.Sprintf("(%s/%s)", pod.Namespace, pod.Name)) } if len(remainingPods) > 0 { return fmt.Errorf("not all pods are terminated yet prior to starting mirror pod test: %v pods that still exist: %v", len(remainingPods), strings.Join(remainingPods, ",")) } return nil }, f.Timeouts.PodDelete, f.Timeouts.Poll).Should(gomega.Succeed()) }) </ins> ginkgo.It("the mirror pod should terminate successfully", func(ctx context.Context) { ginkgo.By("verifying the pod is described as syncing in metrics") gomega.Eventually(ctx, getKubeletMetrics, 5*time.Second, time.Second).Should(gstruct.MatchKeys(gstruct.IgnoreExtras, gstruct.Keys{
Change:
It seems to be valid to add here. Would you like to open a pull request for it? this is like a cleanup, as the set insert will skip and the validation will do twice. is used to track bugs. I suggest you open a PR for that if you like.
/sig storage
I think adding ` == true and we didn't skip, it will insert set twice I believe? wasn't notice that at first glance. However, I can file a PR now
/triage accepted
The label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /triage accepted 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
/triage accepted
Please feel free to submit a PR.

Discussion:
// ValidateCSINodeDrivers tests that the specified CSINodeDrivers have valid data. func validateCSINodeDrivers(drivers []storage.CSINodeDriver, fldPath *field.Path, validationOpts CSINodeValidationOptions) field.ErrorList { allErrs := field.ErrorList{} <del> driverNamesInSpecs := make(sets.String) </del> <ins> driverNamesInSpecs := sets.New[string]() </ins> for i, driver := range drivers { idxPath := fldPath.Index(i) allErrs = append(allErrs, validateCSINodeDriver(driver, driverNamesInSpecs, idxPath, validationOpts)...)

} // validateCSINodeDriver tests if CSINodeDriver has valid entries <del> func validateCSINodeDriver(driver storage.CSINodeDriver, driverNamesInSpecs sets.String, fldPath *field.Path, </del> <ins> func validateCSINodeDriver(driver storage.CSINodeDriver, driverNamesInSpecs sets.Set[string], fldPath *field.Path, </ins> validationOpts CSINodeValidationOptions) field.ErrorList { allErrs := field.ErrorList{}

allErrs = append(allErrs, field.Duplicate(fldPath.Child("name"), driver.Name)) } driverNamesInSpecs.Insert(driver.Name) <del> topoKeys := make(sets.String) </del> <ins> topoKeys := sets.New[string]() </ins> for _, key := range driver.TopologyKeys { if len(key) == 0 { allErrs = append(allErrs, field.Required(fldPath, key))
Change:
Look for "// TODO: Deprecated, remove after we switch to Seccomp field". Fix it. See as example. /cc /help /good-first-issue /sig node add as a reviewer when sending a PR. (issue is a follow up from )
This request has been marked as suitable for new contributors. 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 : Look for "// TODO: Deprecated, remove after we switch to Seccomp field". Fix it. See as example. /good-first-issue /sig node 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
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
I will start to look at it and fix part of them /assign
/assign
/assign
/assign
/assign
I would like to work on this issue. Can you assign this to me? /assign
/assign
Should I work on this Issue? /assign
/assign
Should I work on this Issue? /assign
I believe there is someone working on this now, and in approving phase, so it's kinda done.
Hey, I would like to work on this. /assign
i got it!! /assign
/assign

Discussion:
ReadonlyPaths: securitycontext.ConvertToRuntimeReadonlyPaths(effectiveSc.ProcMount), } } <del> // TODO: Deprecated, remove after we switch to Seccomp field // set SeccompProfilePath. </del> var err error <del> synthesized.SeccompProfilePath, err = m.getSeccompProfilePath(pod.Annotations, container.Name, pod.Spec.SecurityContext, container.SecurityContext, m.seccompDefault) if err != nil { return nil, err } </del> synthesized.Seccomp, err = m.getSeccompProfile(pod.Annotations, container.Name, pod.Spec.SecurityContext, container.SecurityContext, m.seccompDefault) if err != nil {