jiebi/CodeConvo huggingface dataset:
Code change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
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
looks like started a few days ago ! /sig cluster-lifecycle
cc
fix was sent earlier
/sig cluster-lifecycle
thanks :) i saw it yesterday and forgot to raise the issue. i should have checked the PR queue :)

Related discussion:
text: ``` cd kubernetes <del> sudo hack/local-up-cluster.sh </del> <ins> hack/local-up-cluster.sh </ins> ``` This will build and start a lightweight local cluster, consisting of a master
Code change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
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
looks like started a few days ago ! /sig cluster-lifecycle
cc
fix was sent earlier
/sig cluster-lifecycle
thanks :) i saw it yesterday and forgot to raise the issue. i should have checked the PR queue :)

Related discussion:
text: GO_OUT="${KUBE_ROOT}/_output/local/bin/${host_os}/${host_arch}" APISERVER_LOG=/tmp/kube-apiserver.log <del> "${GO_OUT}/kube-apiserver"  </del> <ins> sudo "${GO_OUT}/kube-apiserver"  </ins> -v=${LOG_LEVEL}  --address="${API_HOST}"  --port="${API_PORT}"
Code change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
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
looks like started a few days ago ! /sig cluster-lifecycle
cc
fix was sent earlier
/sig cluster-lifecycle
thanks :) i saw it yesterday and forgot to raise the issue. i should have checked the PR queue :)

Related discussion:
text: kube::util::wait_for_url "http://${API_HOST}:${API_PORT}/api/v1beta1/pods" "apiserver: " CTLRMGR_LOG=/tmp/kube-controller-manager.log <del> "${GO_OUT}/kube-controller-manager"  </del> <ins> sudo "${GO_OUT}/kube-controller-manager"  </ins> -v=${LOG_LEVEL}  --machines="127.0.0.1"  --master="${API_HOST}:${API_PORT}" >"${CTLRMGR_LOG}" 2>&1 & CTLRMGR_PID=$! KUBELET_LOG=/tmp/kubelet.log <del> "${GO_OUT}/kubelet"  </del> <ins> sudo "${GO_OUT}/kubelet"  </ins> -v=${LOG_LEVEL}  --etcd_servers="http://127.0.0.1:4001"  --hostname_override="127.0.0.1"
Code change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
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
looks like started a few days ago ! /sig cluster-lifecycle
cc
fix was sent earlier
/sig cluster-lifecycle
thanks :) i saw it yesterday and forgot to raise the issue. i should have checked the PR queue :)

Related discussion:
text: KUBELET_PID=$! PROXY_LOG=/tmp/kube-proxy.log <del> "${GO_OUT}/kube-proxy"  </del> <ins> sudo "${GO_OUT}/kube-proxy"  </ins> -v=${LOG_LEVEL}  --master="http://${API_HOST}:${API_PORT}" >"${PROXY_LOG}" 2>&1 & PROXY_PID=$! SCHEDULER_LOG=/tmp/kube-scheduler.log <del> "${GO_OUT}/kube-scheduler"  </del> <ins> sudo "${GO_OUT}/kube-scheduler"  </ins> -v=${LOG_LEVEL}  --master="http://${API_HOST}:${API_PORT}" >"${SCHEDULER_LOG}" 2>&1 & SCHEDULER_PID=$!
Code change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
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
looks like started a few days ago ! /sig cluster-lifecycle
cc
fix was sent earlier
/sig cluster-lifecycle
thanks :) i saw it yesterday and forgot to raise the issue. i should have checked the PR queue :)

Related discussion:
text: cleanup() { echo "Cleaning up..." <del> kill "${APISERVER_PID}" kill "${CTLRMGR_PID}" kill "${KUBELET_PID}" kill "${PROXY_PID}" kill "${SCHEDULER_PID}" </del> <ins> sudo kill "${APISERVER_PID}" sudo kill "${CTLRMGR_PID}" sudo kill "${KUBELET_PID}" sudo kill "${PROXY_PID}" sudo kill "${SCHEDULER_PID}" </ins> kill "${ETCD_PID}" rm -rf "${ETCD_DIR}"
Code change:
ci-cgroupv1-containerd-node-arm64-e2e-serial-ec2-eks ci-cgroupv1-containerd-node-e2e-serial-ec2-eks It has been failing consistently for a long time. 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
There's another bug that was filed a long time ago. But there's no update on it and the same test in gce jobs seem to be green now.
cc

Related discussion:
text: } ginkgo.BeforeEach(func() { <ins> // Precautionary check that kubelet is healthy before running the test. waitForKubeletToStart(context.TODO(), f) </ins> ginkgo.By("setting up the pod to be used in the test") e2epod.NewPodClient(f).Create(context.TODO(), testCase.podSpec) })
Code change:
ci-cgroupv1-containerd-node-arm64-e2e-serial-ec2-eks ci-cgroupv1-containerd-node-e2e-serial-ec2-eks It has been failing consistently for a long time. 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
There's another bug that was filed a long time ago. But there's no update on it and the same test in gce jobs seem to be green now.
cc

Related discussion:
text: Name: podName, }, Spec: v1.PodSpec{ <del> RestartPolicy: v1.RestartPolicyNever, </del> <ins> PriorityClassName: "system-node-critical", RestartPolicy:     v1.RestartPolicyNever, </ins> Containers: []v1.Container{ createContainer(ctnName), },
Code change:
ci-cgroupv1-containerd-node-arm64-e2e-serial-ec2-eks ci-cgroupv1-containerd-node-e2e-serial-ec2-eks It has been failing consistently for a long time. 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
There's another bug that was filed a long time ago. But there's no update on it and the same test in gce jobs seem to be green now.
cc

Related discussion:
text: "sh", "-c", // use the dd tool to attempt to allocate huge block of memory which exceeds the node allocatable <del> "sleep 5 && dd if=/dev/zero of=/dev/null iflag=fullblock count=10 bs=10G", </del> <ins> "sleep 5 && dd if=/dev/zero of=/dev/null iflag=fullblock count=10 bs=1024G", </ins> }, SecurityContext: &v1.SecurityContext{ SeccompProfile: &v1.SeccompProfile{
Code change:
ci-kubernetes-unit TestPickBestStrategy shows the jobs are success. but in test-grid and ci report, it shows a failure. After This failed the {Failed;Failed;Failed;Failed;Failed;Failed;Failed; === RUN TestPickBestStrategy === RUN TestPickBestStrategy/singlecandidate,singlepreferredstrategy === RUN TestPickBestStrategy/multiplecandidates,differentpreferredstrategiesshouldfail === RUN TestPickBestStrategy/multiplecandidates,multipleresolvedpreferredstrategy No response_ /sig testing
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
Thanks for opening this Paco, just noticed.
cc
! It is weird as the test passed indeed and I cannot reproduce it.
Fixed in

Related discussion:
text: } if len(sorted) != len(graph) { <del> fmt.Printf("%s", (sorted)) </del> return nil // Cycle detected }
Code change:
seen in this inside a like loop we execute a function that return a bool and an error. If we want to fail fast we return the error directly and assert on the output of the wait function. If we want to retry we log the error and return false nil /kind flake /kind bug /sig testing /sig network
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 since I think you this test but most probable the code is inherited and is a copy paste thing, but besides that, the change is to remove those there
/assign

Related discussion:
text: // our target metric should be updated by now if err := wait.PollUntilContextTimeout(ctx, 10*time.Second, 2*time.Minute, true, func(_ context.Context) (bool, error) { metrics, err := metricsGrabber.GrabFromKubeProxy(ctx, nodeName) <del> framework.ExpectNoError(err) </del> <ins> if err != nil { return false, fmt.Errorf("failed to fetch metrics: %w", err) } </ins> targetMetricAfter, err := metrics.GetCounterMetricValue(metricName) <del> framework.ExpectNoError(err) </del> <ins> if err != nil { return false, fmt.Errorf("failed to fetch metric: %w", err) } </ins> return targetMetricAfter > targetMetricBefore, nil }); err != nil { <del> framework.Failf("expected %s metric to be updated after accessing endpoints via localhost nodeports", metricName) </del> <ins> if wait.Interrupted(err) { framework.Failf("expected %s metric to be updated after accessing endpoints via localhost nodeports", metricName) } framework.ExpectNoError(err) </ins> } }) })
Code change:
The code says this (): While the comment says this (): So..., what happened? The feature is still Alpha or it is a Beta? Be consistent about the features we add or change. Read the code. No response 30.0 <details</details<details</details<details</details<details</details<details</details
According to the changelog: This feature has been demoted from Beta to Alpha. That is fine. We need to revise the code comment then.
/sig api-machinery (not sure who owns it per se)
not worry, i think this can be resolved with
I found same like this inconsistency between the comment and the actual feature gate definition for APIServingWithRoutine in due to this
I want to raise PR on this if need another PR separately
Looks like this comment should be updated to alpha based on . Thanks for catching. if you'd like to raise a PR to fix the comment that'd be great!
/triage accepted
sure I will raise

Related discussion:
text: APIServerTracing featuregate.Feature = "APIServerTracing" // owner: @linxiulei <del> // beta: v1.30 </del> <ins> // alpha: v1.30 </ins> // // Enables serving watch requests in separate goroutines. APIServingWithRoutine featuregate.Feature = "APIServingWithRoutine"
Code change:
k8s component developers are using FQDNs as finalizers (e.g. or which triggers an error message that isn't particularly easy for an end user to understand: To a naive end user, a fully qualified domain name is a pretty safe thing that is unlikely to conflict with anything else (as long as it's only used by someone from within the domain that owns it, which is a reasonable assumption). If the finalizer has s inside it but no , the message should suggest that finalizers need a . Something like: Do whatever it is that triggered the warning in (this is probably simpler than installing cert-manager and asking for a certificate) introduced: <details</details<detailsGKE </details<details</details<details</details<details</details<details</details
/sig api-machinery
If thats ok I would like to work on that.
/assign
/triage accepted

Related discussion:
text: } if len(strings.Split(stringValue, "/")) == 1 { if !standardFinalizers.Has(stringValue) { <del> allWarnings = append(allWarnings, fmt.Sprintf("%s: %q: prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers", fldPath.String(), stringValue)) </del> <ins> if strings.Contains(stringValue, ".") { allWarnings = append(allWarnings, fmt.Sprintf("%s: %q: prefer a domain-qualified finalizer name including a path (/) to avoid accidental conflicts with other finalizer writers", fldPath.String(), stringValue)) } else { allWarnings = append(allWarnings, fmt.Sprintf("%s: %q: prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers", fldPath.String(), stringValue)) } </ins> } } return allWarnings
Code change:
k8s component developers are using FQDNs as finalizers (e.g. or which triggers an error message that isn't particularly easy for an end user to understand: To a naive end user, a fully qualified domain name is a pretty safe thing that is unlikely to conflict with anything else (as long as it's only used by someone from within the domain that owns it, which is a reasonable assumption). If the finalizer has s inside it but no , the message should suggest that finalizers need a . Something like: Do whatever it is that triggered the warning in (this is probably simpler than installing cert-manager and asking for a certificate) introduced: <details</details<detailsGKE </details<details</details<details</details<details</details<details</details
/sig api-machinery
If thats ok I would like to work on that.
/assign
/triage accepted

Related discussion:
text: finalizer: []string{"kubernetes.io/valid-finalizer"}, }, { <ins> name:      "create-crd-with-fqdn-like-finalizer-without-path", finalizer: []string{"finalizer.without.valid-path.io"}, expectCreateWarnings: []string{ `metadata.finalizers: "finalizer.without.valid-path.io": prefer a domain-qualified finalizer name including a path (/) to avoid accidental conflicts with other finalizer writers`, }, }, { </ins> name:             "update-crd-with-invalid-finalizer", finalizer:        []string{"invalid-finalizer"}, updatedFinalizer: []string{"another-invalid-finalizer"},