jiebi/CodeConvo huggingface dataset:
Change:
t.Errorf("The code did panic") } }() n.OnNodeUpdate(oldNode, node) }) } } <ins> func customExit(exitCode int) { panic(strconv.Itoa(exitCode)) } </ins>

Discussion:
There are some cases when kube-proxy has to exit and restart, in order to do that we panic, but this has the problem that the log output shows a literal "panic" message and engineers, support, customers and automation gets confused, thinking that is a problem when is the expected behavior. As suggested by in , we can replace by /sig network /help /kind cleanup
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 : There are some cases when kube-proxy has to exit and restart, in order to do that we panic, but this has the problem that the log output shows a literal "panic" message and engineers, support, customers and automation gets confused, thinking that is a problem when is the expected behavior. /help /kind cleanup </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
/assign I would like to raise a PR to fix this.
Change:
} for _, epInfo := range proxier.endpointsMap[svcPortName] { <ins> if onlyNodeLocalEndpoints && !epInfo.GetIsLocal() { continue } </ins> newEndpoints.Insert(epInfo.String()) }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The test is flaky with the error something like: What you expected to happen: Test should pass /assign
/sig network /area ipvs
/close
Cases are green now. :tada:
Change:
} return lastEvent, nil } <ins> func checkReplicationControllerStatusReplicaCount(f *framework.Framework, rcName string, quantity int32) func() (bool, error) { return func() (bool, error) { framework.Logf("Get Replication Controller %q to confirm replicas", rcName) rc, err := f.ClientSet.CoreV1().ReplicationControllers(f.Namespace.Name).Get(context.TODO(), rcName, metav1.GetOptions{}) if err != nil { return false, err } if rc.Status.Replicas != quantity { return false, nil } framework.Logf("Found %d replicas for %q replication controller", quantity, rc.Name) return true, nil } } </ins>

Discussion:
[X] Test approval issue: [X] Test PR: 29 Sept 2022 [X] Two weeks soak end date: 14 Oct 2022 [X] Test promotion PR: According to this APIsnoop query, there are still two remaining ReplicationControllerScale endpoints which are untested for conformance. readCoreV1NamespacedReplicationControllerScalereplaceCoreV1NamespacedReplicationControllerScale Using a number of existing e2e test practices a new has been created for two ReplicationControllerScale endpoints. The e2e logs for this test are listed below. This query shows which scale endpoints are hit within a short period of running this e2e test If a test with these calls gets merged, test coverage will go up by 2 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
Change:
import ( "context" <ins> "encoding/json" </ins> "fmt" "strconv" "time" <ins> kubeletconfigv1beta1 "k8s.io/kubelet/config/v1beta1" kubeletconfig "k8s.io/kubernetes/pkg/kubelet/apis/config" kubeletconfigscheme "k8s.io/kubernetes/pkg/kubelet/apis/config/scheme" </ins> v1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/kubernetes/test/e2e/framework" <del> e2ekubelet "k8s.io/kubernetes/test/e2e/framework/kubelet" </del> e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper" imageutils "k8s.io/kubernetes/test/utils/image"

Discussion:
ci-kubernetes-e2e-aks-engine-azure-master-windows-containerd-serial-slow Kubernetes e2e suite: [sig-windows] [Feature:Windows] Memory Limits [Serial] [Slow] Allocatable node memory should be equal to a calculated allocatable memory value expandmore this month No response_ /sig windows
/assign
/triage accepted /priority important-soon
Change:
"github.com/onsi/ginkgo" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/util/wait"

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-serial Which test(s) are failing: [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to add nodes [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to delete nodes Since when has it been failing: These tests have been failing since 6/28 Failures coincide with the following changes: Testgrid link: Reason for failure: The failure messages look as follows: [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to add nodes [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to delete nodes /cc /milestone v1.16 /priority critical-urgent /kind failing-test /cc
/sig cluster-lifecycle
For more context, the code for the failing tests is here The error for both comes through  - some Pod is not responding. It is failing to find pods prefixed with "my-hostname-add-node". Within the logs we can see this: So the Pods are stuck in a Pending state. The Pods are supposed to be created by a ReplicationController in , which itself uses this method from the e2e framework . However, after being in a Pending state (after the "failed to wait for pods responding: timed out waiting for the condition" error is registered), they do seem to reach a Ready state
/assign for triage.
I think agnhost needs to be passed , but did not do so in /assign sig-testing
GitHub didn't allow me to assign the following users: sig-testing. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : I think agnhost needs to be passed , but did not do so in 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
Reopen to monitor job /reopen
Reopened this issue.

<detailsIn response to : Reopen to monitor job /reopen 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
Thank you for working on the PR to solve this. indeed solved the issue reported here. /close
Closing this issue. <detailsIn response to : Thank you for working on the PR to solve this. /close 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
Change:
rbacv1 "k8s.io/api/rbac/v1" apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/types" </ins> "k8s.io/apimachinery/pkg/util/sets" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/apimachinery/pkg/util/wait" <ins> watch "k8s.io/apimachinery/pkg/watch" </ins> "k8s.io/kubernetes/plugin/pkg/admission/serviceaccount" "k8s.io/kubernetes/test/e2e/framework" e2ekubectl "k8s.io/kubernetes/test/e2e/framework/kubectl"

Discussion:
[ ] Promotion created According to this APIsnoop query, there are still some remaining ServiceAccount endpoints which are untested. Create a ServiceAccount with a static label Create a Secret Patch the ServiceAccount with a new Label and a new Secret Get the ServiceAccount to ensure it's patched List all ServiceAccounts in all Namespaces find the ServiceAccount(1) ensure that the ServiceAccount is found and is patched Delete Namespaced ServiceAccount(1) via a Collection with a LabelSelector Delete the Secret Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
Fine with moving forward You don't need to check the status of the secret as part of the test. In other places we check that the resource in question happens, we don't have to follow.
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
/retitle Write CoreV1ServiceAccount resource lifecycle test+promote - +3
/close close this Issue in favour of and place in In Progress Issues on org dashboard
Closing this issue. <detailsIn response to : /close close this Issue in favour of and place in In Progress Issues on org dashboard </details
Change:
package prereleaselifecyclegenerators import ( <ins> "fmt" </ins> "reflect" <ins> "strconv" </ins> "testing" "k8s.io/gengo/types" <ins> "k8s.io/klog/v2" </ins> ) var mockType = &types.Type{

Discussion:
The commands under will benefit of a batter unit test coverage as seen in Originally posted by in
/sig api-machinery /assign
GitHub didn't allow me to assign the following users: damiansawicki. Note that only with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /sig api-machinery 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
Hi I would like to work on this issue. Could you tell me how many test files are needed per PR under this issue?
Hi the issue is already assigned to me. Would you consider contributing to other issues to avoid duplication?
Hi do you mind if I work on this issue along with you? I would only like to write tests on limited number of files, if that's okay with you...
Hi thanks for your engagement! If you also want to work on this particular issue, we should coordinate. Are you working on something other than ?
Hey currently I'm thinking of shifting to Do let me know if you are already working on that particular directory. Also I could assist you in any of your work on this issue as I'm not preoccupied at the moment.
Change:
"runtime" "testing" <ins> "github.com/prometheus/common/model" v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime/schema" clientset "k8s.io/client-go/kubernetes"

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: While I was watching grafana for a single run, I noticed that GET requests are reported as LIST requests, e.g. grafana shows ~1K QPS for LIST of pods ! while kube-apiserver's logs show: (there are no pod lists that time). I'm not sure if this is intended change to metrics reporting (kind of unexpected to be honest), but this definitely affects way our scalability tests validate latency metrics: We do not validate GET API call latency at all Validation for LIST requests is also affected, as usually GET API calls are way cheaper than LIST requests, so grouping GET-LISTs and LIST-LISTs together lowers p99 for LISTs. Also perf-dash shows that GET requests simply disappeared at some point: http://perf- ! What you expected to happen: GET requests should be reported with verb=GET in apiserverrequest_total metric. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:

FYI
I managed to narrow the issue by bisecting the runs of which runs load tests using master k/k every 1 hour. This is the last test run that had GETs reported correctly: This is the first test run that has no GETs reported: Looking at the k/k repo commits' hashes inside artifacts in both runs and at what happened between each of them it looks as if might be the culprit.
From the former run's artifacts: This is (among others) what we miss in the latter run - this is understandable from the point of view of this if condition: Why did the reported GETs have as the scope instead of in the first place, however??
It seems that our handing is incorrect: vs Or my understanding of it was incorrect.

It seems that the semantic is: cluster - for cluster-scope requests namespace - for namespace-scoped requests request - for subresources I think the assumption in the monitoring path was: cluster - for cluster-scope requests namespace - for namespace-scope requests requests - for requests touching a single resource (not necessary subresource) I'm not 100% sure which semantic we should use - based on the finding we should fix one or the other place...
cc There should probably be a unit test mapping URL paths to the expected label values.
is opened to fix that.
/triage accepted
Change:
} func (f *flexVolumeUnmounter) TearDownAt(dir string) error { pathExists, pathErr := mount.PathExists(dir) <del> if !pathExists { klog.Warningf("Warning: Unmount skipped because path does not exist: %v", dir) return nil } if pathErr != nil && !mount.IsCorruptedMnt(pathErr) { return fmt.Errorf("Error checking path: %v", pathErr) </del> <ins> if pathErr != nil { // only log warning here since plugins should anyways have to deal with errors klog.Warningf("Error checking path: %v", pathErr) } else { if !pathExists { klog.Warningf("Warning: Unmount skipped because path does not exist: %v", dir) return nil } </ins> } call := f.plugin.NewDriverCall(unmountCmd)

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: pod could not be terminated when pod volume path is corrupted, and it looks like it mainly affect flexvolume, not sure What you expected to happen: How to reproduce it (as minimally and precisely as possible): a pod with smb mount (we use flexvol in this case, driver is ) smb server password the pod could not be terminated forever Anything else we need to know?: Environment: Kubernetes version (use ): master Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others: /sig storage /assign cc
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Workaround on agent node, run “mount | grep cifs” to get all cifs mounts check every cifs mount, failed (in above example), run: And then the pod will be in terminated soon.
Change:
//     apiVersion: kubeadm.k8s.io/v1beta2 //     kind: ClusterConfiguration // <del> //     apiVersion: kubelet.config.k8s.io/v1beta2 </del> <ins> //     apiVersion: kubelet.config.k8s.io/v1beta1 </ins> //     kind: KubeletConfiguration // //     apiVersion: kubeproxy.config.k8s.io/v1alpha1

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: references and a broken link to this (because it doesn't exist!) I'm guessing this was a bad find and replace when copying kubeadm's own v1beta1 to v1beta2 What you expected to happen: accurate documentation How to reproduce it (as minimally and precisely as possible): read the docs Anything else we need to know?: this template has a lot of fields :^) Environment: anything Kubernetes version (use ): n/a Cloud provider or hardware configuration: n/a OS (e.g: ): n/a Kernel (e.g. ): n/a Install tools: kubeadm Network plugin and version (if this is a network-related bug): n/a Others: n/a /assign /sig cluster-lifecycle
Change:
ipv6Primary := kl.nodeIP != nil && utilnet.IsIPv6(kl.nodeIP) var iptClients []utiliptables.Interface <ins> var protocols []utiliptables.Protocol </ins> if maybeDualStack || !ipv6Primary { <ins> protocols = append(protocols, utiliptables.ProtocolIPv4) </ins> iptClients = append(iptClients, utiliptables.New(exec, utiliptables.ProtocolIPv4)) } if maybeDualStack || ipv6Primary { <ins> protocols = append(protocols, utiliptables.ProtocolIPv6) </ins> iptClients = append(iptClients, utiliptables.New(exec, utiliptables.ProtocolIPv6)) } <del> for _, iptClient := range iptClients { kl.syncNetworkUtil(iptClient) go iptClient.Monitor( utiliptables.Chain("KUBE-KUBELET-CANARY"), []utiliptables.Table{utiliptables.TableMangle, utiliptables.TableNAT, utiliptables.TableFilter}, func() { kl.syncNetworkUtil(iptClient) }, 1*time.Minute, wait.NeverStop, ) </del> <ins> for i := range iptClients { iptClient := iptClients[i] if kl.syncNetworkUtil(iptClient) { klog.Infof("Initialized %s iptables rules.", protocols[i]) go iptClient.Monitor( utiliptables.Chain("KUBE-KUBELET-CANARY"), []utiliptables.Table{utiliptables.TableMangle, utiliptables.TableNAT, utiliptables.TableFilter}, func() { kl.syncNetworkUtil(iptClient) }, 1*time.Minute, wait.NeverStop, ) } else { klog.Warningf("Failed to initialize %s iptables rules; some functionality may be missing.", protocols[i]) } </ins> } }

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: ci-kubernetes-e2e-gci-gce-alpha-features Which test(s) are failing: Networking should recreate its iptables rules if they are deleted [Disruptive] Since when has it been failing: Commit Testgrid link: Reason for failure: Anything else we need to know: Possibly related to this? It's listed in the git diff /sig network
/assign /cc Thanks for detecting it so quicklly
most probably is related to
/unassign /assign he has already submitted a fix
/triage accepted
Reviewed. Marking as resolved on the CI Signal Board. Once was merged, failures stopped and they have not re-occurred in the last 8 days (Oct 10th)
Yay
Change:
var containers []corev1.Container ctn := corev1.Container{ Name:  fmt.Sprintf("%s-ctn", w.Name()), <del> Image: "gcr.io/kubernetes-e2e-test-images/node-perf/npb-ep-amd64:1.0", </del> <ins> Image: "gcr.io/kubernetes-e2e-test-images/node-perf/npb-ep:1.0", </ins> Resources: corev1.ResourceRequirements{ Requests: corev1.ResourceList{ corev1.ResourceName(corev1.ResourceCPU):    resource.MustParse("15000m"),

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: test/e2enode/perf tests are referring to adm only images, this need to be replaced with multi-arch fat manifest images. ref:
/assign /sig node
Change:
volumeSpec *volume.Spec, uniquePodName volumetypes.UniquePodName, mountedVolumesForPod map[volumetypes.UniquePodName]map[string]cache.MountedVolume) { <del> if podVolume.PersistentVolumeClaim == nil { </del> <ins> if podVolume.PersistentVolumeClaim == nil || pvc == nil { </ins> // Only PVC supports resize operation. return }

Discussion:
The following test failures started happening on 30th March: Kubernetes e2e suite.[sig-storage] In-tree Volumes [Driver: aws] [Testpattern: Inline-volume (default fs)] volumes should allow exec of files on the volume Kubernetes e2e suite.[sig-storage] In-tree Volumes [Driver: aws] [Testpattern: Inline-volume (default fs)] volumes should store data Kubernetes e2e suite.[sig-storage] In-tree Volumes [Driver: aws] [Testpattern: Inline-volume (ext4)] volumes should allow exec of files on the volume Kubernetes e2e suite.[sig-storage] In-tree Volumes [Driver: aws] [Testpattern: Inline-volume (ext4)] volumes should store data See This seems related to the changes in kubelet fails with the following: Tests passing See the e2e logs above No response <detailsLatest CI build </details<detailsAWS </details<details</details<details</details<details</details<detailsEBS CSI driver 1.5.0 </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
/cc
/sig storage
/assign
not having debugging kops builds for awhile, are kubelet logs attached in prow? I don't see them...
Spoke with offline. It looks like we don't have kubelet logs captured in these tests. I need complete kubelet logs to make sense of these errors because testgrid shows inline volume tests as failing and code in question should not be called or inline volumes (because they can not be expanded). If that code fails, it would have been failing before too. I will wait for logs from and in the meanwhile try and see if I can reproduce these failures in single node AWS cluster setup that I can build manually.
thanks
Looks like this is happening for inline volumes if CSI migration is enabled for them. We construct a "fake" object on the fly for migration enabled plugins even though volume is inline, which is causing this condition to fail. It should be simple fix.
opened to fix the problem. The code change is just one line but has tests.