jiebi/CodeConvo huggingface dataset:
Change:
/kind failing-test /sig scheduling This flakes before in and was fixed by . As this test is not flaky a lot, the priority may not be that high. But as this is a conformance test, we'd better to know why this would happen.
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

Discussion:
ginkgo.By("Creating a Pod with more than former max resources") pod = newTestPod(podName+"2", getResourceList("600m", "600Mi", "600Gi"), v1.ResourceList{}) <del> _, err = f.ClientSet.CoreV1().Pods(f.Namespace.Name).Create(ctx, pod, metav1.CreateOptions{}) </del> <ins> // When the LimitRanger admission plugin find 0 items from the LimitRange informer cache, // it will try to lookup LimitRanges from the local LiveLookupCache which liveTTL is 30s. // If a LimitRange was deleted from the apiserver, informer watch the delete event and then // handle it lead to the informer cache doesn't have any other items, but the local LiveLookupCache // has it and not expired at the same time, the LimitRanger admission plugin will use the // deleted LimitRange to validate the request. So the request will be rejected by the plugin // till the item is expired. // // With the following retry, we can make sure the item is expired and the request will be // validated as expected. err = framework.Gomega().Eventually(ctx, func(ctx context.Context) error { _, err = f.ClientSet.CoreV1().Pods(f.Namespace.Name).Create(ctx, pod, metav1.CreateOptions{}) return err }).WithPolling(5 * time.Second).WithTimeout(30 * time.Second).ShouldNot(gomega.HaveOccurred()) </ins> framework.ExpectNoError(err) })
Change:
master-informing: ! Last 2 runs failed consecutively, first failure: No response /sig storage
/cc
I will take a look this week.
/triage accepted
/assign

Discussion:
pvNamePrefix := ns + "-" pvHostPathConfig := e2epv.PersistentVolumeConfig{ <del> NamePrefix: pvNamePrefix, Labels:     volLabel, </del> <ins> NamePrefix:       pvNamePrefix, Labels:           volLabel, StorageClassName: ns, </ins> PVSource: v1.PersistentVolumeSource{ CSI: &v1.CSIPersistentVolumeSource{ Driver:       csiDriver.Name,

}, }, } <ins> pvcConfig := e2epv.PersistentVolumeClaimConfig{ StorageClassName: &ns, } </ins> numPVs, numPVCs := 1, 1 pvols, claims, err = e2epv.CreatePVsPVCs(ctx, numPVs, numPVCs, c, f.Timeouts, ns, pvHostPathConfig, pvcConfig)

}, } <ins> pvcConfig := e2epv.PersistentVolumeClaimConfig{ StorageClassName: &ns, } </ins> numPVs, numPVCs := 1, 1 pvols, claims, err = e2epv.CreatePVsPVCs(ctx, numPVs, numPVCs, c, f.Timeouts, ns, pvHostPathConfig, pvcConfig) framework.ExpectNoError(err, "Failed to create the requested storage resources")
Change:
The check in: is incorrect. It misses the case when the sysctl doesn't exist (err != nil). /sig network /area ipvs /area kube-proxy The check sould be: To reproduce you must use a kernel without the function, or the module unloaded. This is likely not easy if a regular Linux distro is used. But IMO no e2e testing should be needed (none exist now). It's just a warning that may be missed, so nothing urgent. master (all) N/A N/A N/A N/A N/A
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
/good-first-issue
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 : /good-first-issue </details
removed one of those , it looks that we should remove this to be consistent
I can work on removing the code to maintain consistency. Can you please assign this issue to me
/assign You can also use to assign the issue to yourself.
oops, I should have thought to check ipvs backend too

Discussion:
// In IPVS proxy mode, the following flags need to be set const ( <del> sysctlBridgeCallIPTables      = "net/bridge/bridge-nf-call-iptables" </del> sysctlVSConnTrack             = "net/ipv4/vs/conntrack" sysctlConnReuse               = "net/ipv4/vs/conn_reuse_mode" sysctlExpireNoDestConn        = "net/ipv4/vs/expire_nodest_conn"

nodePortAddressStrings []string, kernelHandler KernelHandler, ) (*Proxier, error) { <del> // Proxy needs br_netfilter and bridge-nf-call-iptables=1 when containers // are connected to a Linux bridge (but not SDN bridges).  Until most // plugins handle this, log when config is missing if val, err := sysctl.GetSysctl(sysctlBridgeCallIPTables); err == nil && val != 1 { klog.InfoS("Missing br-netfilter module or unset sysctl br-nf-call-iptables, proxy may not work as intended") } </del> // Set the conntrack sysctl we need for if err := proxyutil.EnsureSysctl(sysctl, sysctlVSConnTrack, 1); err != nil { return nil, err
Change:
Compare requestdurationseconds, requestterminationstotal, requestabortstotal API server metrics between the two runs. The acceptable delta should be less than 20%. xref:
/sig auth /triage accepted
/assign ritazh /milestone v1.29

Discussion:
<ins> #!/bin/bash # Copyright 2014 Google Inc. All rights reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # Bring up a Kubernetes cluster. # # If the full release name (gs://<bucket>/<release>) is passed in then we take # that directly.  If not then we assume we are doing development stuff and take # the defaults in the release config. set -o errexit set -o nounset set -o pipefail KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. KUBE_CONFIG_FILE="config-default.sh" ${KUBE_ROOT}/hack/ginkgo-e2e.sh --ginkgo.focus=Networking </ins>  No newline at end of file
Change:
[x] test approval issue : [x] test pr : [x] Flake [x] two weeks soak end date : 31 Oct 2023 [X] test promotion pr : [X] remove endpoint from According to following APIsnoop query, there are three PersistentVolume and three PersistentVolumeClaim endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 6 endpoints. The e2e logs for this test are listed below. This query shows the following PV and PVC 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 6 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted /cc
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion 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

Discussion:
- getResourceAPIGroup - listStorageV1CSINode - listStorageV1VolumeAttachment <del> - patchCoreV1NamespacedPersistentVolumeClaimStatus - patchCoreV1PersistentVolumeStatus </del> - patchStorageV1CSINode - patchStorageV1VolumeAttachment - patchStorageV1VolumeAttachmentStatus <del> - readCoreV1NamespacedPersistentVolumeClaimStatus - readCoreV1PersistentVolumeStatus </del> - readStorageV1CSINode - readStorageV1VolumeAttachment - readStorageV1VolumeAttachmentStatus <del> - replaceCoreV1NamespacedPersistentVolumeClaimStatus - replaceCoreV1PersistentVolumeStatus </del> - replaceStorageV1CSINode - replaceStorageV1VolumeAttachment - replaceStorageV1VolumeAttachmentStatus
Change:
Presubmit job - Job History: The periodic job in the test grid is found to be flaky as well. Following are some of the tests that are found to be flaky The flakiness is observed almost since the job's inception Pod status/cache seems to be not getting updated correctly between the two immediate calls of a pod and hence resulting in the creation of duplicate containers within the same pod. Also, the seems to be non-blocking when the Evented PLEG is enabled and hence resulting in the creation of duplicate containers when there are immediate multiple calls before the pod status/cache is updated. No response_ /sig node
/kind bug
/assign
/triage accepted /remove-kind bug
We are experiencing this issue Similarly, we are using cgroup v1 also.

Discussion:
// Otherwise, it returns nil. The caller should acquire the lock. func (c *cache) getIfNewerThan(id types.UID, minTime time.Time) *data { d, ok := c.pods[id] <del> if utilfeature.DefaultFeatureGate.Enabled(features.EventedPLEG) { // Evented PLEG has CREATED, STARTED, STOPPED and DELETED events // However if the container creation fails for some reason there is no // CRI event received by the kubelet and that pod will get stuck a // GetNewerThan call in the pod workers. This is reproducible with // the node e2e test, // https://github.com/kubernetes/kubernetes/blob/83415e5c9e6e59a3d60a148160490560af2178a1/test/e2e_node/pod_hostnamefqdn_test.go#L161 // which forces failure during pod creation. This issue also exists in // Generic PLEG but since it updates global timestamp periodically // the GetNewerThan call gets unstuck. // During node e2e tests, it was observed this change does not have any // adverse impact on the behaviour of the Generic PLEG as well. switch { case !ok: return makeDefaultData(id) case ok && (d.modified.After(minTime) || (c.timestamp != nil && c.timestamp.After(minTime))): return d default: return nil } } </del> globalTimestampIsNewer := (c.timestamp != nil && c.timestamp.After(minTime)) if !ok && globalTimestampIsNewer { // Status is not cached, but the global timestamp is newer than
Change:
In and , I started seeing these flakes. The job in question has not been very flaky before so this is odd. In and , I started seeing these flakes. The job "Job should not create pods when created in suspend state" is the one that is flaking. Triage says a few days ago. No response No response /sig apps
Did some digging and I did not see any changes that could account for an increase of flakiness in the job controller code. There was a change made to the e2e tests: The logs say: The code is pretty simple so I wonder if we are hitting a case where sometimes the suspend condition is not set and we fail. Maybe we could add a consistent call here?
/triage accepted /priority important-soon
/cc
/reopen /assign do you mind monitoring the CI state for 1 or 2 days to confirm your PR really fixed it ?
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
It makes sense to me.
cc I think this issue has been fixed. Can we close it?
/close Thanks for the fix. The test is not flaky now.
Closing this issue. <detailsIn response to : 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

Discussion:
args: args, // PodStart is used as default because waiting for a pod is the // most common operation. <del> timeout:  TestContext.timeouts.PodStart, interval: TestContext.timeouts.Poll, </del> <ins> timeout:      TestContext.timeouts.PodStart, interval:     TestContext.timeouts.Poll, consistently: consistently, </ins> } }
Change:
In 1.26 the service controller in the Kubernetes cloud controller manage (KCCM) introduced a new mechanism for syncing load balancers based on predicates. The predicates applied will depend on "service classes", specifically if it's or , see: This implementation is not well suited for internal GCP load balancers which use InstanceGroups. from Google, feel free to correct me: any cluster has all nodes grouped together into an instance group. Service of have individual GCP load balancers, but these load balancers end up referencing the same instance group (which is the cluster's instance group). This means that the inclusion/exclusion predicates for any service, will trickle down and impact the cluster's global instance group, thereby impacting other services which don't necessarily apply the same set of predicates. Ex: services exclude nodes, whereas do not. A Node going will therefore be removed from all backends for services, however on GCP with load balancer solution based on InstanceGroups: this means that the same node will be removed from all backends for services too. This is NOT a problem on = 1.27 using the feature , because all services on 1.27 using that feature gate will have the same set of predicates. Node updates requiring the removal of the instance from load balancers belonging to services of should not impact other services of . Bring up a cluster using "Internal load balancers" on GCP. Define two services, one being and the other . Have one node go . The instance corresponding to that Node might be removed from the InstanceGroup backend of the service. This will depend on the order the services are synced, if the service is synced last then the instance will be removed. This is actually not really that bad, because the only different predicate between both is the readiness condition - and a node should go back to if all is fine, and finally be included. But I wanted to raise this for issue for completeness sake so that it is known. <details</details<detailsGCP </details<details</details<details</details<details</details<details</details
/sig network /sig cloud-provider /cc
/triage accepted

Discussion:
etpLocalNodePredicates []NodeConditionPredicate = []NodeConditionPredicate{ nodeIncludedPredicate, nodeUnTaintedPredicate, <ins> nodeReadyPredicate, </ins> } stableNodeSetPredicates []NodeConditionPredicate = []NodeConditionPredicate{ nodeNotDeletedPredicate,

}, }, expectedUpdateCalls: []fakecloud.UpdateBalancerCall{ <ins> {Service: etpLocalservice1, Hosts: []*v1.Node{node1, node3}}, {Service: etpLocalservice2, Hosts: []*v1.Node{node1, node3}}, </ins> {Service: service3, Hosts: []*v1.Node{node1, node3}}, }, }, {

}, }, expectedUpdateCalls: []fakecloud.UpdateBalancerCall{ <ins> {Service: etpLocalservice1, Hosts: []*v1.Node{node1, node2, node3}}, {Service: etpLocalservice2, Hosts: []*v1.Node{node1, node2, node3}}, </ins> {Service: service3, Hosts: []*v1.Node{node1, node2, node3}}, }, }, {
Change:
The Huge pages test in both containerd/cri is consistently failing. Not sure. No response There was a deprecation for ExpectEqual merged about a week ago on this same line. maybe you could take a look and see why this check is failing? modified this line /sig node
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

Discussion:
framework.ExpectNoError(err, "while getting node status") ginkgo.By("Verifying that the node now supports huge pages with size 3Mi") <del> gomega.Expect(node.Status.Capacity).To(gomega.HaveKeyWithValue("hugepages-3Mi", resource.MustParse("9Mi")), "capacity should contain resource hugepages-3Mi and huge pages with size 3Mi should be supported") </del> <ins> value, ok := node.Status.Capacity["hugepages-3Mi"] if !ok { framework.Failf("capacity should contain resource hugepages-3Mi: %v", node.Status.Capacity) } gomega.Expect(value.String()).To(gomega.Equal("9Mi"), "huge pages with size 3Mi should be supported") </ins> ginkgo.By("restarting the node and verifying that huge pages with size 3Mi are not supported") restartKubelet(true)
Change:
These tests are completely failing due to a compilation issue so no tests are running. NA You can go to the containerd logs in artifacts and see that GLIBC_2.34 is not found. Typically these fixes can be resolved by an image update. These tests don't seem to point to any default image. /sig node
One of these is not like the other! Looks like ci-cos-cgroupv2-containerd-node-e2e is failing due to a missing clone of containerd. fixes ci-cos-cgroupv2-containerd-node-e2e.
/assign I noticed that the jobs were passing with image , started failing with image . I've filed an internal support case, will post more updates later.
/triage accepted /priority important-soon
COS team came back to us, it seems that the change is in how containerd is compiled (lGLIBC versions are the same across both images). I'll take a look at this issue next week, as I'm oncall this one.
This PR fixed this issue. I striked it out on this issue.
Added to the list as this is also failing for a similar reason.
Containerd can be built statically to avoid this kind of issues: ~/git/containerd (1.7.7) $ ldd bin/containerd not a dynamic executable
We don't even need to statically rebuild containerd to fix this as statically built binaries are published by the containerd project as part of their releases, e.g.
The binaries that we use in testing are from the main branch of containerd. So getting a static binary from the release is not an option.
What is the glibc version used in ? The reason of failure may be because the  image that is used for building containerd switched from bullseye to bookworm which has
Correct. However, we can still statically build containerd binaries or ask containerd maintainers to publish prebuilt static binaries from their main branch. With dynamically built executables we're going to have this kind of issues in future.
/reopen Looks like did not fix this so reopening the issue.
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
second attempt to fix it:
Nice work
Thank you. is not triggered yet. Next run will be tomorrow. I hope it's fixed.

Discussion:
# By default, the latest image from the image family will be used unless an # explicit image will be set. GCI_VERSION=${KUBE_GCI_VERSION:-} <del> IMAGE_FAMILY=${KUBE_IMAGE_FAMILY:-cos-97-lts} </del> <ins> IMAGE_FAMILY=${KUBE_IMAGE_FAMILY:-cos-109-lts} </ins> export MASTER_IMAGE=${KUBE_GCE_MASTER_IMAGE:-} export MASTER_IMAGE_FAMILY=${KUBE_GCE_MASTER_IMAGE_FAMILY:-${IMAGE_FAMILY}} export MASTER_IMAGE_PROJECT=${KUBE_GCE_MASTER_PROJECT:-cos-cloud}
Change:
As we are debugging nodee2e tests, we realize that we are missing kubelet logs and services. Kubelet logs allow us to see problems with kubelet which would be useful for all nodee2e jobs. Services are the other components that are started. I saw some warnings related to startup of apiserver so it would be nice to have these logs to troubleshoot.
/sig node
/assign
/triage accepted /priority important-longterm was this changed recently? I remember having seen not so long ago
It depends what tests you are looking at. The Kind e2e one do have but I didn't see any in the node_e2e ones. I'll do some research into that.
you are correct. Some of the jobs do have I am still trying to find out why a select few tests have a lot more logs than others. One thing I am noticing is that the jobs that are migrated to the community cluster seem to have much fewer logs. For example, is not yet migrated to the community cluster and it looks like we get a bunch of logs. Job Config: is migrated to community cluster and I don't see any extra logs here. Job Config:
/assign

Discussion:
return fmt.Errorf("failed to create log directory %q: %w", logPath, err) } // Copy logs (if any) to artifacts/hostname <del> if _, err := SSH(host, "ls", fmt.Sprintf("%s:%s/results/*.log", GetHostnameOrIP(host), testDir)); err == nil { </del> <ins> if _, err := SSH(host, "ls", fmt.Sprintf("%s/results/*.log", testDir)); err == nil { </ins> if _, err := runSSHCommand(host, "scp", "-r", fmt.Sprintf("%s:%s/results/*.log", GetHostnameOrIP(host), testDir), logPath); err != nil { return err }
Change:
Seen in and in No hits on stack strace nothing evident on the git history of the test itself, but it seems , so most probable something in the device manager has changed? /sig node /kind flake
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 as this flakes a lot in

Discussion:
m.mutex.Lock() defer m.mutex.Unlock() <del> if _, exists := m.endpoints[resourceName]; exists { </del> <ins> if ep, exists := m.endpoints[resourceName]; exists { </ins> m.markResourceUnhealthy(resourceName) <del> klog.V(2).InfoS("Endpoint became unhealthy", "resourceName", resourceName, "endpoint", m.endpoints[resourceName]) } </del> <ins> klog.V(2).InfoS("Endpoint became unhealthy", "resourceName", resourceName, "endpoint", ep) </ins> <del> m.endpoints[resourceName].e.setStopTime(time.Now()) </del> <ins> ep.e.setStopTime(time.Now()) } </ins> } // PluginListAndWatchReceiver receives ListAndWatchResponse from a device plugin

klog.ErrorS(err, "Unable to connect to device plugin client with socket path", "path", c.socket) return err } <ins> c.mutex.Lock() </ins> c.grpc = conn c.client = client <ins> c.mutex.Unlock() </ins> return c.handler.PluginConnected(c.resource, c) }