jiebi/CodeConvo huggingface dataset:
Code change:
From the Deprecated API Migration Guide: , since v1.19, the has been using the new reportingController and reportingInstance to replace the decrecated source.component and But when I checked the Kube events in a cluster with version 1.26.0, those new fields are empty and the supposed to be deprecated fields have not been renamed. Seeing the values in the new fields like reportingController and reportingInstance an Kubernetes cluster with version 1.26.0 some Kube events the Kube events details for the field of reportingController, reportingInstance, source.component, No response <detailsServer Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2022-12-11T00:15:47Z", GoVersion:"go1.19.4", Compiler:"gc", Platform:"linux/amd64"} </details<detailsAzure </details<details</details<details</details<details</details<details</details
/sig instrumentation
I have also encountered this issue in my local 1.26.0 Kubernetes cluster, which does not align with the deprecation guide described in I believe I can investigate this further
/assign
Thank you for making the PR to fix this! Also a comment in the PR for the doc update.
/triage accepted

Related discussion:
text: APIVersion: "v1", FieldPath:  "spec.containers[2]", }, <del> Reason:  "Started", Message: "some verbose message: 1", Source:  v1.EventSource{Component: "eventTest"}, Count:   3, Type:    v1.EventTypeNormal, </del> <ins> Reason:              "Started", Message:             "some verbose message: 1", Source:              v1.EventSource{Component: "eventTest"}, ReportingController: "eventTest", Count:               3, Type:                v1.EventTypeNormal, </ins> }, expectLog:    `Event(v1.ObjectReference{Kind:"Pod", Namespace:"baz", Name:"foo", UID:"bar", APIVersion:"v1", ResourceVersion:"", FieldPath:"spec.containers[2]"}): type: 'Normal' reason: 'Started' some verbose message: 1`, expectUpdate: true,
Code change:
From the Deprecated API Migration Guide: , since v1.19, the has been using the new reportingController and reportingInstance to replace the decrecated source.component and But when I checked the Kube events in a cluster with version 1.26.0, those new fields are empty and the supposed to be deprecated fields have not been renamed. Seeing the values in the new fields like reportingController and reportingInstance an Kubernetes cluster with version 1.26.0 some Kube events the Kube events details for the field of reportingController, reportingInstance, source.component, No response <detailsServer Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2022-12-11T00:15:47Z", GoVersion:"go1.19.4", Compiler:"gc", Platform:"linux/amd64"} </details<detailsAzure </details<details</details<details</details<details</details<details</details
/sig instrumentation
I have also encountered this issue in my local 1.26.0 Kubernetes cluster, which does not align with the deprecation guide described in I believe I can investigate this further
/assign
Thank you for making the PR to fix this! Also a comment in the PR for the doc update.
/triage accepted

Related discussion:
text: APIVersion: "v1", FieldPath:  "spec.containers[3]", }, <del> Reason:  "Stopped", Message: "some verbose message: 1", Source:  v1.EventSource{Component: "eventTest"}, Count:   1, Type:    v1.EventTypeNormal, </del> <ins> Reason:              "Stopped", Message:             "some verbose message: 1", Source:              v1.EventSource{Component: "eventTest"}, ReportingController: "eventTest", Count:               1, Type:                v1.EventTypeNormal, </ins> }, expectLog:    `Event(v1.ObjectReference{Kind:"Pod", Namespace:"baz", Name:"foo", UID:"differentUid", APIVersion:"v1", ResourceVersion:"", FieldPath:"spec.containers[3]"}): type: 'Normal' reason: 'Stopped' some verbose message: 1`, expectUpdate: false,
Code change:
From the Deprecated API Migration Guide: , since v1.19, the has been using the new reportingController and reportingInstance to replace the decrecated source.component and But when I checked the Kube events in a cluster with version 1.26.0, those new fields are empty and the supposed to be deprecated fields have not been renamed. Seeing the values in the new fields like reportingController and reportingInstance an Kubernetes cluster with version 1.26.0 some Kube events the Kube events details for the field of reportingController, reportingInstance, source.component, No response <detailsServer Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2022-12-11T00:15:47Z", GoVersion:"go1.19.4", Compiler:"gc", Platform:"linux/amd64"} </details<detailsAzure </details<details</details<details</details<details</details<details</details
/sig instrumentation
I have also encountered this issue in my local 1.26.0 Kubernetes cluster, which does not align with the deprecation guide described in I believe I can investigate this further
/assign
Thank you for making the PR to fix this! Also a comment in the PR for the doc update.
/triage accepted

Related discussion:
text: APIVersion: "v1", FieldPath:  "spec.containers[3]", }, <del> Reason:  "Stopped", Message: "some verbose message: 1", Source:  v1.EventSource{Component: "eventTest"}, Count:   2, Type:    v1.EventTypeNormal, </del> <ins> Reason:              "Stopped", Message:             "some verbose message: 1", Source:              v1.EventSource{Component: "eventTest"}, ReportingController: "eventTest", Count:               2, Type:                v1.EventTypeNormal, </ins> }, expectLog:    `Event(v1.ObjectReference{Kind:"Pod", Namespace:"baz", Name:"foo", UID:"differentUid", APIVersion:"v1", ResourceVersion:"", FieldPath:"spec.containers[3]"}): type: 'Normal' reason: 'Stopped' some verbose message: 1`, expectUpdate: true,
Code change:
From the Deprecated API Migration Guide: , since v1.19, the has been using the new reportingController and reportingInstance to replace the decrecated source.component and But when I checked the Kube events in a cluster with version 1.26.0, those new fields are empty and the supposed to be deprecated fields have not been renamed. Seeing the values in the new fields like reportingController and reportingInstance an Kubernetes cluster with version 1.26.0 some Kube events the Kube events details for the field of reportingController, reportingInstance, source.component, No response <detailsServer Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2022-12-11T00:15:47Z", GoVersion:"go1.19.4", Compiler:"gc", Platform:"linux/amd64"} </details<detailsAzure </details<details</details<details</details<details</details<details</details
/sig instrumentation
I have also encountered this issue in my local 1.26.0 Kubernetes cluster, which does not align with the deprecation guide described in I believe I can investigate this further
/assign
Thank you for making the PR to fix this! Also a comment in the PR for the doc update.
/triage accepted

Related discussion:
text: // Temp clear time stamps for comparison because actual values don't matter for comparison recvEvent.FirstTimestamp = expectedEvent.FirstTimestamp recvEvent.LastTimestamp = expectedEvent.LastTimestamp <ins> recvEvent.ReportingController = expectedEvent.ReportingController </ins> // Check that name has the right prefix. if n, en := recvEvent.Name, expectedEvent.Name; !strings.HasPrefix(n, en) { t.Errorf("%v - Name '%v' does not contain prefix '%v'", messagePrefix, n, en)
Code change:
tc.shutdownActive is captured by 'func' literals in 'go' statements(Line177), it may cause a data race. I use t.Run(..., ){...}() or t.Run() {...}(tc) to avoid it . I don't know whether it is accurate, so I 'm looking forward to your reply. Data Race Nil No response <detailsNil </details<detailsNil </details<details</details<details</details<details</details<details</details
/sig node
Target file:
/area test /priority backlog
have you observed any test failures or this is found by code analysis?
Yes, it is found by code analysis. In terms of the source code, the scenario can happen.
/assign
/remove-kind bug /kind failing-test since it is not a product bug, but the test issue
Although each test case calls a goroutine, tests run serially and block on the goroutine return, so it doesn't look like it could cause an issue. However, to be safe we can create a local copy of inside the loop. I'll send a PR briefly.
Created to address this.
/triage accepted /priority important-longterm

Related discussion:
text: } for _, tc := range tests { <ins> tc := tc </ins> t.Run(tc.desc, func(t *testing.T) { fakeSystemBus := &fakeSystemDBus{} bus := DBusCon{
Code change:
Example: this PR seems to be flaking: comparing age of a node from the output of two commands: Kubernetes e2e suite: [It] [sig-cli] Kubectl client kubectl subresource flag GET on status subresource of built-in type (node) returns identical info as GET on the built-in type expandless 5 hours back No response No response No response_ /sig cli
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
/priority important-soon
it seems that is comparing subresources and there is something there that changes over time As Sergey correctly points out is the Age The test can not assume the executions will be done in the same second
/assign

Related discussion:
text: outBuiltIn := e2ekubectl.RunKubectlOrDie("", "get", "nodes", node.Name) ginkgo.By(fmt.Sprintf("calling kubectl get nodes %s --subresource=status", node.Name)) outStatusSubresource := e2ekubectl.RunKubectlOrDie("", "get", "nodes", node.Name, "--subresource=status") <del> gomega.Expect(outBuiltIn).To(gomega.Equal(outStatusSubresource)) </del> <ins> // Avoid comparing values of fields that might end up // changing between the two invocations of kubectl. requiredOutput := [][]string{ {"NAME"}, {"STATUS"}, {"ROLES"}, {"AGE"}, {"VERSION"}, {node.Name},                           // check for NAME {""},                                  // avoid comparing STATUS {""},                                  // avoid comparing ROLES {""},                                  // avoid comparing AGE {node.Status.NodeInfo.KubeletVersion}, // check for VERSION } checkOutput(outBuiltIn, requiredOutput) checkOutput(outStatusSubresource, requiredOutput) </ins> }) }) })
Code change:
The following log line is often (~30times) logged during our tests in : . This suggests a possible bug as it was assumed to do not happen. No log line saying . Look at artifacts of all (or almost all) builds of: No response <details</details<detailsReproducible in tests </details<details</details<details</details<details</details<details</details
/sig node FYI
/triage accepted since it's a new error, it is a regression. So adding a corresponding priority /priority important-soon
are you working on this? Should I assign bug to you?
Yes, I'm taking a look at this. /assign
/cc
This is a metrics only error (we don’t report a fraction of metrics) and has no functional impact.
That makes sense, but is it expected that this is a valid state in first place? . My assumption was that if static is false, (i.e. API pod) then we should have a config?
I took a closer look at the logs, it seems that this is happening when we enter while a static pod is being synced which has UID reuse and another pod which has the same full name did not terminate yet. In this case, we block the static pod from starting i.e. () returns false: Because the pod can't start, we don't set : which means that when we log metrics there is no set and thus or are both defaulted to false:
Based on the above, it looks like this case is expected. As a result, maybe the simplest option is to simply drop the log statement since by design we only want to into account a subset of the states for the metrics?

Related discussion:
text: // or can be started, and updates the cached pod state so that downstream components can observe what the // pod worker goroutine is currently attempting to do. If ok is false, there is no available event. If any // of the boolean values is false, ensure the appropriate cleanup happens before returning. <ins> // // This method should ensure that either status.pendingUpdate is cleared and merged into status.activeUpdate, // or when a pod cannot be started status.pendingUpdate remains the same. Pods that have not been started // should never have an activeUpdate because that is exposed to downstream components on started pods. </ins> func (p *podWorkers) startPodSync(podUID types.UID) (ctx context.Context, update podWork, canStart, canEverStart, ok bool) { p.podLock.Lock() defer p.podLock.Unlock()
Code change:
The following log line is often (~30times) logged during our tests in : . This suggests a possible bug as it was assumed to do not happen. No log line saying . Look at artifacts of all (or almost all) builds of: No response <details</details<detailsReproducible in tests </details<details</details<details</details<details</details<details</details
/sig node FYI
/triage accepted since it's a new error, it is a regression. So adding a corresponding priority /priority important-soon
are you working on this? Should I assign bug to you?
Yes, I'm taking a look at this. /assign
/cc
This is a metrics only error (we don’t report a fraction of metrics) and has no functional impact.
That makes sense, but is it expected that this is a valid state in first place? . My assumption was that if static is false, (i.e. API pod) then we should have a config?
I took a closer look at the logs, it seems that this is happening when we enter while a static pod is being synced which has UID reuse and another pod which has the same full name did not terminate yet. In this case, we block the static pod from starting i.e. () returns false: Because the pod can't start, we don't set : which means that when we log metrics there is no set and thus or are both defaulted to false:
Based on the above, it looks like this case is expected. As a result, maybe the simplest option is to simply drop the log statement since by design we only want to into account a subset of the states for the metrics?

Related discussion:
text: klog.V(4).InfoS("Pod cannot start ever", "pod", klog.KObj(update.Options.Pod), "podUID", podUID, "updateType", update.WorkType) return ctx, update, canStart, canEverStart, true case !canStart: <ins> // this is the only path we don't start the pod, so we need to put the change back in pendingUpdate status.pendingUpdate = &update.Options </ins> status.working = false klog.V(4).InfoS("Pod cannot start yet", "pod", klog.KObj(update.Options.Pod), "podUID", podUID) return ctx, update, canStart, canEverStart, true
Code change:
The following log line is often (~30times) logged during our tests in : . This suggests a possible bug as it was assumed to do not happen. No log line saying . Look at artifacts of all (or almost all) builds of: No response <details</details<detailsReproducible in tests </details<details</details<details</details<details</details<details</details
/sig node FYI
/triage accepted since it's a new error, it is a regression. So adding a corresponding priority /priority important-soon
are you working on this? Should I assign bug to you?
Yes, I'm taking a look at this. /assign
/cc
This is a metrics only error (we don’t report a fraction of metrics) and has no functional impact.
That makes sense, but is it expected that this is a valid state in first place? . My assumption was that if static is false, (i.e. API pod) then we should have a config?
I took a closer look at the logs, it seems that this is happening when we enter while a static pod is being synced which has UID reuse and another pod which has the same full name did not terminate yet. In this case, we block the static pod from starting i.e. () returns false: Because the pod can't start, we don't set : which means that when we log metrics there is no set and thus or are both defaulted to false:
Based on the above, it looks like this case is expected. As a result, maybe the simplest option is to simply drop the log statement since by design we only want to into account a subset of the states for the metrics?

Related discussion:
text: State:  status.WorkType(), Orphan: orphan, } <del> if status.activeUpdate != nil && status.activeUpdate.Pod != nil { sync.HasConfig = true sync.Static = kubetypes.IsStaticPod(status.activeUpdate.Pod) </del> <ins> switch { case status.activeUpdate != nil: if status.activeUpdate.Pod != nil { sync.HasConfig = true sync.Static = kubetypes.IsStaticPod(status.activeUpdate.Pod) } case status.pendingUpdate != nil: if status.pendingUpdate.Pod != nil { sync.HasConfig = true sync.Static = kubetypes.IsStaticPod(status.pendingUpdate.Pod) } </ins> } workers[uid] = sync }
Code change:
If a pod is created and then deleted an entry in processedPods map remains forever (sometimes, it's racy). The problem comes from the fact that calls volume_manager asynchronously. If the last call happens after populator cleaned up resources, an entry is to processedPods and will never be seen. An entry in processedPods map must be deleted if pod doesn't exist and pod runtime should removed according to . To verify that the issue really exists I applaied a simple printing resources in map. Here is a reproducer: brand-new fresh k8s cluster with entries in : a pod, check its uid: that this uid is accurately reported: the pod, wait for a few mins, check for again: The entry will be kept forever because kubelet doesn't know anything about this pod anymore: so no more events will ever come to populater for this uid, and the loop in won't find it because it was already deleted from . n/a <details</details<detailsany </details<details</details<details</details<details</details<details</details
/sig storage
/triage accepted
/priority impoerant-soon
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority impoerant-soon 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
/priority important-soon
/assign
PR () fixed this issue. It is ready to merge since Mar 21.
/assign

Related discussion:
text: // Iterate through all pods in desired state of world, and remove if they no // longer exist func (dswp *desiredStateOfWorldPopulator) findAndRemoveDeletedPods() { <ins> podsFromCache := make(map[volumetypes.UniquePodName]struct{}) </ins> for _, volumeToMount := range dswp.desiredStateOfWorld.GetVolumesToMount() { <ins> podsFromCache[volumetypes.UniquePodName(volumeToMount.Pod.UID)] = struct{}{} </ins> pod, podExists := dswp.podManager.GetPodByUID(volumeToMount.Pod.UID) if podExists {
Code change:
If a pod is created and then deleted an entry in processedPods map remains forever (sometimes, it's racy). The problem comes from the fact that calls volume_manager asynchronously. If the last call happens after populator cleaned up resources, an entry is to processedPods and will never be seen. An entry in processedPods map must be deleted if pod doesn't exist and pod runtime should removed according to . To verify that the issue really exists I applaied a simple printing resources in map. Here is a reproducer: brand-new fresh k8s cluster with entries in : a pod, check its uid: that this uid is accurately reported: the pod, wait for a few mins, check for again: The entry will be kept forever because kubelet doesn't know anything about this pod anymore: so no more events will ever come to populater for this uid, and the loop in won't find it because it was already deleted from . n/a <details</details<detailsany </details<details</details<details</details<details</details<details</details
/sig storage
/triage accepted
/priority impoerant-soon
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority impoerant-soon 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
/priority important-soon
/assign
PR () fixed this issue. It is ready to merge since Mar 21.
/assign

Related discussion:
text: dswp.deleteProcessedPod(volumeToMount.PodName) } <ins> // Cleanup orphanded entries from processedPods dswp.pods.Lock() orphanedPods := make([]volumetypes.UniquePodName, 0, len(dswp.pods.processedPods)) for k := range dswp.pods.processedPods { if _, ok := podsFromCache[k]; !ok { orphanedPods = append(orphanedPods, k) } } dswp.pods.Unlock() for _, orphanedPod := range orphanedPods { uid := types.UID(orphanedPod) _, podExists := dswp.podManager.GetPodByUID(uid) if !podExists && dswp.podStateProvider.ShouldPodRuntimeBeRemoved(uid) { dswp.deleteProcessedPod(orphanedPod) } } </ins> podsWithError := dswp.desiredStateOfWorld.GetPodsWithErrors() for _, podName := range podsWithError { if _, podExists := dswp.podManager.GetPodByUID(types.UID(podName)); !podExists {
Code change:
If a pod is created and then deleted an entry in processedPods map remains forever (sometimes, it's racy). The problem comes from the fact that calls volume_manager asynchronously. If the last call happens after populator cleaned up resources, an entry is to processedPods and will never be seen. An entry in processedPods map must be deleted if pod doesn't exist and pod runtime should removed according to . To verify that the issue really exists I applaied a simple printing resources in map. Here is a reproducer: brand-new fresh k8s cluster with entries in : a pod, check its uid: that this uid is accurately reported: the pod, wait for a few mins, check for again: The entry will be kept forever because kubelet doesn't know anything about this pod anymore: so no more events will ever come to populater for this uid, and the loop in won't find it because it was already deleted from . n/a <details</details<detailsany </details<details</details<details</details<details</details<details</details
/sig storage
/triage accepted
/priority impoerant-soon
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority impoerant-soon 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
/priority important-soon
/assign
PR () fixed this issue. It is ready to merge since Mar 21.
/assign

Related discussion:
text: t.Fatalf("Failed to remove pods from desired state of world since they no longer exist") } <ins> // podWorker may call volume_manager WaitForUnmount() after we processed the pod in findAndRemoveDeletedPods() dswp.ReprocessPod(podName) dswp.findAndRemoveDeletedPods() // findAndRemoveDeletedPods() above must detect orphaned pod and delete it from the map if _, ok := dswp.pods.processedPods[podName]; ok { t.Fatalf("Failed to remove orphanded pods from internal map") } </ins> volumeExists := dswp.desiredStateOfWorld.VolumeExists(expectedVolumeName, "" /* SELinuxContext */) if volumeExists { t.Fatalf(