jiebi/CodeConvo huggingface dataset:
Change:
master-informing: capz-windows-master ! 07-10 17:46 IST No response /sig cli cc
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
/kind failing-test
Looking at the failure and tracing the recent code changes, the test was recently modified for the regex pattern match as part of this PR which comes with deprecation of the golang-based short version information in favor of making the --short the new default. But the output of kubectl version is still reflecting the older long format which is causing this test to fail.
/assign

Discussion:
// we expect following values for: Major -> digit, Minor -> numeric followed by an optional '+',  GitCommit -> alphanumeric requiredItems := []string{"Client Version: ", "Server Version: "} for _, item := range requiredItems { <del> if matched, _ := regexp.MatchString(item+`vd.d+.[dw-.+]+`, versionString); !matched { </del> <ins> // prior to 1.28 we printed long version information oldMatched, _ := regexp.MatchString(item+`version.Info{Major:"d", Minor:"d++?", GitVersion:"vd.d+.[dw-.+]+", GitCommit:"[0-9a-f]+"`, versionString) // 1.28+ prints short information newMatched, _ := regexp.MatchString(item+`vd.d+.[dw-.+]+`, versionString) // due to backwards compatibility we need to match both until 1.30 most likely if !oldMatched && !newMatched { </ins> framework.Failf("Item %s value is not valid in %sn", item, versionString) } }
Change:
The seems to be wrong, should be instead of No response <details</details<detailsI am running local Kubernetes cluster using kind. </details<details</details<detailsDocker Desktop for Mac Kind Kubernetes Cluster </details<detailsDocker </details<detailskindnet </details
/sig cli
/triage accepted /priority backlog would you like to fix this mistyping?
Yes Sir! Abid
Hello, can i work on this as my first contribution pls ?
Actually this will be first for me also
please assign yourself and work on it
/assign
/assign
I will assign it to myself once I get home, I am away right now. Thanks
- How unethical it is that you are assigning an issue that you have not pointed out. It is much better that you find a issue and repot it and then assign it. Please go ahead and unassign it, I will assign it and will work on it. CC
/assign
As you opened issue and said that you are planning to work on this, you fully deserve to work on that issue. I'm sorry that I did not check the assignee and approved the PR fixing this. next time, I highly suggest that check if there is assignee or not and only start work on it, only if there is noone.
Oh sorry I thought you said 'please assign yourself and work on it'. I will cancel my PR. I am really sorry.
I was on my phone and i received a mail, so I though it was you who said that ... I cancelled the PR.

Discussion:
flags := NewEventsFlags(restClientGetter, streams) cmd := &cobra.Command{ <del> Use:                   fmt.Sprintf("events [(-o|--output=)%s] [--for TYPE/NAME] [--watch] [--event=Normal,Warning]", strings.Join(flags.PrintFlags.AllowedFormats(), "|")), </del> <ins> Use:                   fmt.Sprintf("events [(-o|--output=)%s] [--for TYPE/NAME] [--watch] [--types=Normal,Warning]", strings.Join(flags.PrintFlags.AllowedFormats(), "|")), </ins> DisableFlagsInUseLine: true, Short:                 i18n.T("List events"), Long:                  eventsLong,
Change:
In the events , the PVC has been successfully resized, but a warning-level log is still printed. And by checking the logs of kube-controller-manager, can see the following output. Do not print events with warning level. To expand a a CSI PVC, and then use "kubectl describe pvc" to view its events. (I am using xsky CSI to expand pvc, but based on my understanding of Kubernetes code, this issue can occur with any CSI.) ! ! Based on Kubernetes v1.27.3, I some logs in the func located in . These logs printed all the plugins before expansion, and I noticed that was not among them. In my understanding, it is normal for CSI to be absent from the plugins here because CSI expansion is scheduled through external-resizer instead of kube-controller-manager. Therefore, there should not be any warning-level logs printed here either. v1.27.3 (In version 1.18, the issue can also be reproduced) <details</detailsLinux debian-hk 5.10.0-23-amd64 SMP Debian 5.10.179-1 (2023-05-12) x86_64 GNU/Linux kind v0.20.0 <details</details<details</details
/sig storage
We can change the ExternalExpanding event from Warning to Info. are you interested in making this change?
/triage accepted
Yes, I will submit the pull request in the next few days.
Hi Have you submitted the PR? I have a bugfix branch tested on v1.29.1. I would like to cherry-pick it to master if this is not fixed yet or not started.
You can go do it. Thank you!

Discussion:
package volume import ( <ins> "errors" </ins> "fmt" "net" "strings"

ProbeRemove ) <ins> var ErrNoPluiginMatched = errors.New("no volume plugin matched") </ins> // VolumeOptions contains option information about a volume. type VolumeOptions struct { // The attributes below are required by volume.Provisioner

} if len(matchedPluginNames) == 0 { <del> return nil, fmt.Errorf("no volume plugin matched") </del> <ins> return nil, ErrNoPluiginMatched </ins> } if len(matchedPluginNames) > 1 { return nil, fmt.Errorf("multiple volume plugins matched: %s", strings.Join(matchedPluginNames, ","))

klog.V(4).InfoS("FindExpandablePluginBySpec -> returning noopExpandableVolumePluginInstance", "specName", spec.Name()) return &noopExpandableVolumePluginInstance{spec}, nil } <ins> if errors.Is(err, ErrNoPluiginMatched) { return nil, nil } </ins> klog.V(4).InfoS("FindExpandablePluginBySpec -> err", "specName", spec.Name(), "err", err) return nil, err }
Change:
Node e2e features is failing after PR for graduating swap to beta is merged. After is merged. Test needs to be adjusted for the extra field for swap usage. No response /sig node
/cc
/assign
/triage accepted /priority critical-urgent

Discussion:
memoryCapacity := node.Status.Capacity["memory"] memoryLimit := memoryCapacity.Value() <del> matchResourceMetrics := gstruct.MatchAllKeys(gstruct.Keys{ </del> <ins> matchResourceMetrics := gomega.And(gstruct.MatchKeys(gstruct.IgnoreMissing, gstruct.Keys{ </ins> "scrape_error": gstruct.Ignore(), "node_cpu_usage_seconds_total": gstruct.MatchAllElements(nodeID, gstruct.Elements{ "": boundedSample(1, 1e6),

fmt.Sprintf("%s::%s", f.Namespace.Name, pod0): boundedSample(10*e2evolume.Kb, 80*e2evolume.Mb), fmt.Sprintf("%s::%s", f.Namespace.Name, pod1): boundedSample(10*e2evolume.Kb, 80*e2evolume.Mb), }), <del> }) </del> <ins> "pod_swap_usage_bytes": gstruct.MatchElements(podID, gstruct.IgnoreExtras, gstruct.Elements{ fmt.Sprintf("%s::%s", f.Namespace.Name, pod0): boundedSample(0*e2evolume.Kb, 80*e2evolume.Mb), fmt.Sprintf("%s::%s", f.Namespace.Name, pod1): boundedSample(0*e2evolume.Kb, 80*e2evolume.Mb), }), }), haveKeys("scrape_error", "node_cpu_usage_seconds_total", "node_memory_working_set_bytes", "container_cpu_usage_seconds_total", "container_memory_working_set_bytes", "container_start_time_seconds", "pod_cpu_usage_seconds_total", "pod_memory_working_set_bytes"), ) </ins> ginkgo.By("Giving pods a minute to start up and produce metrics") gomega.Eventually(ctx, getResourceMetrics, 1*time.Minute, 15*time.Second).Should(matchResourceMetrics) ginkgo.By("Ensuring the metrics match the expectations a few more times")

"Histogram": gstruct.Ignore(), })) } <ins> func haveKeys(keys ...string) types.GomegaMatcher { gomega.ExpectWithOffset(1, keys).ToNot(gomega.BeEmpty()) matcher := gomega.HaveKey(keys[0]) if len(keys) == 1 { return matcher } for _, key := range keys[1:] { matcher = gomega.And(matcher, gomega.HaveKey(key)) } return matcher } </ins>
Change:
! /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
Sidecar PR is merged in 07/08. /cc Another potential root cause is according to
The last successful run is on Jul 05, 2023.
/triage accepted
! FYI: ^ this test started failing on 07/08.
Yes, the spec is wrong. I guess it was trying to use pod's not container's (which was ignored before the SidecarContainers PR) I'll propose a fix. /assign

Discussion:
containers: - name: %s image: %s <del> restartPolicy: %s </del> command: ["sh", "-c", "i=0; while [ $i -lt %d ]; do %s i=$(($i+1)); done; while true; do sleep 5; done"] <ins> restartPolicy: %s </ins> ` file := staticPodPath(dir, name, namespace) <del> podYaml := fmt.Sprintf(template, name, namespace, name, image, string(restart), iterations, command) </del> <ins> podYaml := fmt.Sprintf(template, name, namespace, name, image, iterations, command, string(restart)) </ins> f, err := os.OpenFile(file, os.O_RDWR|os.O_TRUNC|os.O_CREATE, 0666) if err != nil {
Change:
pull-kubernetes-unit TestJobApiBackoffReset Unclear, test was last modified in June in Seen most recently in No response No response No response /sig batch cc
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : ### Which jobs are flaking? cc 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
/sig apps /assign mimowo It could be related to ? Or maybe it was always flaky. just in case cc
/wg batch
Thanks for the heads up, I will take a look
Ok, I think I know the issue, which is very similar to another flaky test fixed in the past. The issue is when we shift the fake clock with during (invoked by ), which processes the pending queue () asynchronously. More details on the similar past issue: (). I was able to repro this manually by inserting short real-clock sleeps like here: I think the issue was introduced actually here by the use of fake clock: This commit was to master after 1.27 so no need for cherry-picking the fix. I think the fix is to call instead of , because it repeatedly shifts the fake clock after is processed.

Discussion:
if retries != 1 { t.Fatalf("%s: expected exactly 1 retry, got %d", job.Name, retries) } <ins> // await for the actual requeue after processing of the pending queue is done awaitForQueueLen(ctx, t, manager, 1) </ins> // the queue is emptied on success fakePodControl.Err = nil <del> manager.clock.Sleep(fastJobApiBackoff) </del> manager.processNextWorkItem(context.TODO()) verifyEmptyQueue(ctx, t, manager) }
Change:
TestRoundTrip I checked that 2 weeks ago is not flaking. " install": 14, openapi and validation flake are also . No response No response /sig api-machinery
Easy to reproduce on local env.
My mistake, not this pr.
is the root cause of the flake. /cc
I didn't read far enough, the error was: deepcopy is manual for jsonprops was the manual impl that's no longer valid since we have a pointer now /assign
Working on a targeted fix now
(the last time a field was here, the same thing happened - )
Confirmed that the deep copy fix works as expected: I'll send out a PR in a moment.
Thanks for addressing it!
/triage accepted

Discussion:
} if in.XValidations != nil { <del> in, out := &in.XValidations, &out.XValidations *out = make([]ValidationRule, len(*in)) copy(*out, *in) </del> <ins> inValidations, outValidations := &in.XValidations, &out.XValidations *outValidations = make([]ValidationRule, len(*inValidations)) for i := range *inValidations { in.XValidations[i].DeepCopyInto(&out.XValidations[i]) } </ins> } return out
Change:
The arg large-cluster-size-threshold for kube-controller-manager works as zone size threshold when determining node eviction rate. If there are multiple zones, the description for arg stating "cluster" threshold would be missleading. ARG: Matched arg description Multiple zones cluster No response <details</details<details</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
/sig docs

Discussion:
"where N means number of retries allowed for kubelet to post node status.") fs.Float32Var(&o.NodeEvictionRate, "node-eviction-rate", 0.1, "Number of nodes per second on which pods are deleted in case of node failure when a zone is healthy (see --unhealthy-zone-threshold for definition of healthy/unhealthy). Zone refers to entire cluster in non-multizone clusters.") fs.Float32Var(&o.SecondaryNodeEvictionRate, "secondary-node-eviction-rate", 0.01, "Number of nodes per second on which pods are deleted in case of node failure when a zone is unhealthy (see --unhealthy-zone-threshold for definition of healthy/unhealthy). Zone refers to entire cluster in non-multizone clusters. This value is implicitly overridden to 0 if the cluster size is smaller than --large-cluster-size-threshold.") <del> fs.Int32Var(&o.LargeClusterSizeThreshold, "large-cluster-size-threshold", 50, fmt.Sprintf("Number of nodes from which %s treats the cluster as large for the eviction logic purposes. --secondary-node-eviction-rate is implicitly overridden to 0 for clusters this size or smaller.", names.NodeLifecycleController)) </del> <ins> fs.Int32Var(&o.LargeClusterSizeThreshold, "large-cluster-size-threshold", 50, fmt.Sprintf("Number of nodes from which %s treats the cluster as large for the eviction logic purposes. --secondary-node-eviction-rate is implicitly overridden to 0 for clusters this size or smaller. Notice: If nodes reside in multiple zones, this threshold will be considered as zone node size threshold for each zone to determine node eviction rate independently.", names.NodeLifecycleController)) </ins> fs.Float32Var(&o.UnhealthyZoneThreshold, "unhealthy-zone-threshold", 0.55, "Fraction of Nodes in a zone which needs to be not Ready (minimum 3) for zone to be treated as unhealthy. ") }

return nc.evictionLimiterQPS } <del> // ReducedQPSFunc returns the QPS for when a the cluster is large make </del> <ins> // ReducedQPSFunc returns the QPS for when the cluster is large make </ins> // evictions slower, if they're small stop evictions altogether. func (nc *Controller) ReducedQPSFunc(nodeNum int) float32 { if int32(nodeNum) > nc.largeClusterThreshold {
Change:
I upgraded k3s from to and noticed a log message is repeated in the I also see this message when deploying a container that uses apiserver aggregation, such as in other distros such as in the api-server log. The message should not repeated in the logs. This causes a nuisance and the logs eventually are rotated. Upgrade kubernetes to and install a container that uses uses apiserver aggregation such as or . For reference the original issue was reported here: <details</details<details</details<details</details<details</details<details</details<details</details
/cc /sig api-machinery The log was in since v1.26.
Thanks for raising this, opened as a potential fix.
/triage accepted
/assign

Discussion:
} func (rdm *resourceDiscoveryManager) addGroupVersionLocked(source Source, groupName string, value apidiscoveryv2beta1.APIVersionDiscovery) { <del> klog.Infof("Adding GroupVersion %s %s to ResourceManager", groupName, value.Version) </del> if rdm.apiGroups == nil { rdm.apiGroups = make(map[groupKey]*apidiscoveryv2beta1.APIGroupDiscovery)

} rdm.apiGroups[key] = group } <ins> klog.Infof("Adding GroupVersion %s %s to ResourceManager", groupName, value.Version) </ins> gv := metav1.GroupVersion{Group: groupName, Version: value.Version} gvKey := groupVersionKey{
Change:
After is fixed, there are still several failing cases. This one is one of them. /kind failing-test /sig node /cc
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
Super weird, still looking but appears to be segfaulting. but it works fine if I manually run the container with , I've tried both with and without a TTY.
Switching from to eliminated the segfault and the test passes. The binary from the 1.29-4 container works fine on this system outside of the pod, and works fine using a container manually started with . Trying to identify why it fails with 1.29-4 when run from a pod, but not ctr directly. I built a busybox top v1.29 binary with debugging information into a new image to debug further, and no crash.
HUH!!! wow.

Discussion:
Command: []string{ "sh", "-c", <del> "trap "echo SIGTERM caught" SIGTERM SIGINT; touch /tmp/healthy; sleep 1000", </del> <ins> "trap "echo SIGTERM caught" SIGTERM SIGINT; touch /tmp/healthy; /bin/sleep 1000", </ins> }, // Using readiness probe to guarantee signal handler registering finished ReadinessProbe: &v1.Probe{

configs[AuthenticatedWindowsNanoServer] = Config{list.GcAuthenticatedRegistry, "windows-nanoserver", "v1"} configs[APIServer] = Config{list.PromoterE2eRegistry, "sample-apiserver", "1.17.7"} configs[AppArmorLoader] = Config{list.PromoterE2eRegistry, "apparmor-loader", "1.4"} <del> configs[BusyBox] = Config{list.PromoterE2eRegistry, "busybox", "1.29-4"} </del> <ins> configs[BusyBox] = Config{list.PromoterE2eRegistry, "busybox", "1.36.1-1"} </ins> configs[CudaVectorAdd] = Config{list.PromoterE2eRegistry, "cuda-vector-add", "1.0"} configs[CudaVectorAdd2] = Config{list.PromoterE2eRegistry, "cuda-vector-add", "2.3"} configs[DistrolessIptables] = Config{list.BuildImageRegistry, "distroless-iptables", "v0.2.7"}
Change:
ci-cgroupv1-containerd-node-arm64-al2023-e2e-ec2-eks E2eNode Suite: [It] [sig-node] Summary API [NodeConformance] when querying /stats/summary should report resource usage through the stats api { failed [FAILED] Timed out after 180.001s. Expected <string: Summary to match fields: { .Node.SystemContainers: missing expected element runtime } In [It] at: @ 07/26/23 05:48:05.248 } arm test since begining cadvisor on arm? /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
/cc
/assign it may be ec2 related, not arm related. We need to fix arm tests on gce to validate (failing currently).
Should be fixed, but I'm watching and will re-open if not.
Test is passing now, good to leave closed.

Discussion:
return result, err } <ins> func makePodStatus(info interface{}) string { if state, ok := info.(map[string]interface{})["State"]; ok { if running, ok := state.(map[string]interface{})["Running"]; ok { if running.(bool) { return "Running" } else { return "Stopped" } } } return "Pending" } </ins> func (storage *PodRegistryStorage) Get(id string) (interface{}, error) { pod, err := storage.registry.GetPod(id) if err != nil {

return pod, err } pod.CurrentState.Info = info <ins> pod.CurrentState.Status = makePodStatus(info) </ins> pod.Kind = "cluster#pod" return pod, err }

"foobar": "bar", "baz":    "blah", }) <ins> } func TestMakePodStatus(t *testing.T) { status := makePodStatus(map[string]interface{}{}) if status != "Pending" { t.Errorf("Expected 'Pending', got '%s'", status) } status = makePodStatus(map[string]interface{}{ "State": map[string]interface{}{ "Running": false, }, }) if status != "Stopped" { t.Errorf("Expected 'Stopped', got '%s'", status) } status = makePodStatus(map[string]interface{}{ "State": map[string]interface{}{ "Running": true, }, }) if status != "Running" { t.Errorf("Expected 'Running', got '%s'", status) } </ins> }
Change:
seems like an infra issue. No tests run 7/21 No response No response /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
/cc
/cc
ssh connection timeouts: Which weird given that it ran on the default network and there is a firewall rule in there that allows ssh from anywhere.
Got a fix, another regression from I really need to get these kubetest2 jobs ran as presubmits by default on k/k ASAP.

Discussion:
} func (g *GCERunner) machineType(machine string) string { <ins> var ret string </ins> if machine == "" && *instanceType != "" { <del> machine = *instanceType </del> <ins> ret = *instanceType } else if machine != "" { ret = machine </ins> } else { <del> machine = defaultGCEMachine </del> <ins> ret = defaultGCEMachine </ins> } <del> return fmt.Sprintf("zones/%s/machineTypes/%s", *zone, machine) </del> <ins> return fmt.Sprintf("zones/%s/machineTypes/%s", *zone, ret) </ins> } func (g *GCERunner) rebootInstance(instance *compute.Instance) error { // wait until the instance will not response to SSH