jiebi/CodeConvo huggingface dataset:
Change:
changed from "kube-dns" to "core-dns". "core-dns" is failing for me on Debian Buster: works when I use . "core-dns" should work. Perhaps related to this? Kubernetes version (use ): current master () OS (e.g: ): Debian Buster Kernel (e.g. ): 5.5.0-0.bpo.2-amd64 /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
provides a description of the error, causes, and workarounds. Typically this is due to a local dns resolver installed on the host. Solution is to configure kubelet to use a different (more detail in link).
That mirrors what I found through the issue. Needs to be fixed in then.
/sig testing /cc
/cc
I think we have to parameterize this
I think the safer way is to configure kublet to send the correct to all “default” dns policy pods, not just fix in coredns.
Doh, right :)

Discussion:
EXTERNAL_HOSTNAME=${EXTERNAL_HOSTNAME:-localhost} KUBELET_HOST=${KUBELET_HOST:-"127.0.0.1"} <ins> KUBELET_RESOLV_CONF=${KUBELET_RESOLV_CONF:-"/etc/resolv.conf"} </ins> # By default only allow CORS for requests on localhost API_CORS_ALLOWED_ORIGINS=${API_CORS_ALLOWED_ORIGINS:-/127.0.0.1(:[0-9]+)?$,/localhost(:[0-9]+)?$} KUBELET_PORT=${KUBELET_PORT:-10250}

rotateCertificates: true runtimeRequestTimeout: "${RUNTIME_REQUEST_TIMEOUT}" staticPodPath: "${POD_MANIFEST_PATH}" <ins> resolvConf: "${KUBELET_RESOLV_CONF}" </ins> EOF { # authentication
Change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
/sig node
I find the reason for it, but I don't know the solution is suitable, correct me if not.
/triage accepted /assign

Discussion:
"k8s.io/kubernetes/pkg/kubelet/nodeshutdown/systemd" ) <ins> // lock is to prevent systemDbus from being modified in the case of concurrency. var lock sync.Mutex </ins> type fakeDbus struct { currentInhibitDelay        time.Duration overrideSystemInhibitDelay time.Duration

fakeShutdownChan := make(chan bool) fakeDbus := &fakeDbus{currentInhibitDelay: tc.systemInhibitDelay, shutdownChan: fakeShutdownChan, overrideSystemInhibitDelay: tc.overrideSystemInhibitDelay} <ins> lock.Lock() </ins> systemDbus = func() (dbusInhibiter, error) { return fakeDbus, nil }

manager.clock = clock.NewFakeClock(time.Now()) err := manager.Start() <ins> lock.Unlock() </ins> if tc.expectedError != nil { if !strings.Contains(err.Error(), tc.expectedError.Error()) { t.Errorf("unexpected error message. Got: %s want %s", err.Error(), tc.expectedError.Error())

var shutdownChanMut sync.Mutex var connChan = make(chan struct{}, 1) <ins> lock.Lock() </ins> systemDbus = func() (dbusInhibiter, error) { defer func() { connChan <- struct{}{}

nodeRef := &v1.ObjectReference{Kind: "Node", Name: "test", UID: types.UID("test"), Namespace: ""} manager, _ := NewManager(fakeRecorder, nodeRef, activePodsFunc, killPodsFunc, syncNodeStatus, shutdownGracePeriodRequested, shutdownGracePeriodCriticalPods) err := manager.Start() <ins> lock.Unlock() </ins> if err != nil { t.Errorf("unexpected error: %v", err) }
Change:
<!-- 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 --While working on , I realized that implements another rather than using the one already implemented in I'm not sure why this was re-implemented, but if we can migrate to using itself, then the code in the package can be cleaned up significantly (as part of ). I expect areas of the codebase that make use of a real clock to consistently use instead of re-implementing it NA Another (slightly) related issue: 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:
/remove-kind bug /kind cleanup /sig auth
/cc fyi
/assign
Better yet, use the one in
/sig api-machinery
/assign /triage accepted

Discussion:
api "k8s.io/kubernetes/pkg/apis/core" eventratelimitapi "k8s.io/kubernetes/plugin/pkg/admission/eventratelimit/apis/eventratelimit" "k8s.io/kubernetes/plugin/pkg/admission/eventratelimit/apis/eventratelimit/validation" <ins> "k8s.io/utils/clock" </ins> ) // PluginName indicates name of admission plugin.

return nil, errs.ToAggregate() } } <del> return newEventRateLimit(configuration, realClock{}) </del> <ins> return newEventRateLimit(configuration, clock.RealClock{}) </ins> }) }

<del> /* Copyright 2017 The Kubernetes Authors. 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. */ package eventratelimit import ( "time" ) // realClock implements flowcontrol.Clock in terms of standard time functions. type realClock struct{} // Now is identical to time.Now. func (realClock) Now() time.Time { return time.Now() } // Sleep is identical to time.Sleep. func (realClock) Sleep(d time.Duration) { time.Sleep(d) } </del>
Change:
Conformance - GCE- master - kubetest2 Kubernetes e2e suite: BeforeSuite kubetest2: Test Kubernetes e2e suite: BeforeSuite: kubetest2: Test Build log /sig scheduling /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
I didn't dig much into this failures, but 3/3 failures I saw are because the konnectivity agent fails to be scheduled due to cpu constraints, is it the environment or the konnectivity agent? or both?
/remove sig-network /remove-sig network
/remove-sig network
I'm not sure if the environment changed recently. looking at the commit range when it started to fail seems suspect cc
Sorry for that. Let me check. is to add toleration for . So it may be scheduled to a node with taint node. Should we remove the toleration for NoSchedule?
is to which is just asked for NoExecute toleration. I follow up kube-proxy and node-local-dns DaemonSet toleration settings and add both NoExecute and NoSchedule. I opened to remove the NoSchedule toleration.
The CI is green now.

Discussion:
operator: "Exists" - operator: "Exists" effect: "NoExecute" <del> - operator: "Exists" effect: "NoSchedule" </del> nodeSelector: kubernetes.io/os: linux containers:
Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Following kubernetes tests are failing make test make test Sample failure error trace Full Test report can be found Incorrect format specifiers used in Errorf in test logging
This we have started seeing with tip golang(1.18) version
/sig storage /sig apps
/triage accepted
/assign

Discussion:
succeededIndexes := succeededIndexesFromJob(&tc.job) err := manager.trackJobStatusAndRemoveFinalizers(&tc.job, tc.pods, succeededIndexes, *uncounted, tc.finishedCond, tc.needsFlush) if !errors.Is(err, tc.wantErr) { <del> t.Errorf("Got error %v, want %w", err, tc.wantErr) </del> <ins> t.Errorf("Got error %v, want %v", err, tc.wantErr) </ins> } if diff := cmp.Diff(tc.wantStatusUpdates, statusUpdates); diff != "" { t.Errorf("Unexpected status updates (-want,+got):n%s", diff)

t.Logf("Running test: %v", tc.name) gotTop, err := translateAllowedTopologies(tc.topology, GCEPDTopologyKey) if err != nil { <del> t.Errorf("Unexpected error: %w", err) </del> <ins> t.Errorf("Unexpected error: %v", err) </ins> } if !reflect.DeepEqual(gotTop, tc.expectedToplogy) {
Change:
<!-- 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 --While reviewing labels in prometheus noticed this metric whose label value is large (700+ characters) since it was a error log message. Example: The metric is from It doesn't look like we should have error/ log message as a metric Query the metric in prometheus UI or through api where kubelet is one of the target in prometheus Kubernetes version (use ): v1.22.0-rc.0 Cloud provider or hardware configuration: NA OS (e.g: ): NA Kernel (e.g. ): NA Install tools: Network plugin and version (if this is a network-related bug): Others: cc:
I agree that error logs should never be part of metrics, it is not the correct vector to convey this kind of information. Logging would be more appropriated here. /sig instrumentation /sig node /cc
I want to work on this. /assign
/triage accepted
/triage accept
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage accept 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:
klog.V(4).InfoS("Pod was deleted and sandbox failed to be created", "pod", klog.KObj(pod), "podUID", pod.UID) return } <del> metrics.StartedPodsErrorsTotal.WithLabelValues(err.Error()).Inc() </del> <ins> metrics.StartedPodsErrorsTotal.Inc() </ins> createSandboxResult.Fail(kubecontainer.ErrCreatePodSandbox, msg) klog.ErrorS(err, "CreatePodSandbox for pod failed", "pod", klog.KObj(pod)) ref, referr := ref.GetReference(legacyscheme.Scheme, pod)

}, ) // StartedPodsErrorsTotal is a counter that tracks the number of errors creating pod sandboxes <del> StartedPodsErrorsTotal = metrics.NewCounterVec( </del> <ins> StartedPodsErrorsTotal = metrics.NewCounter( </ins> &metrics.CounterOpts{ Subsystem:      KubeletSubsystem, Name:           StartedPodsErrorsTotalKey, Help:           "Cumulative number of errors when starting pods", StabilityLevel: metrics.ALPHA, }, <del> []string{"message"}, </del> ) // StartedContainersTotal is a counter that tracks the number of container creation operations StartedContainersTotal = metrics.NewCounterVec(
Change:
<!-- 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 --/kind bug /sig cloud-provider /area provider/azure Azure in-tree CCM fails to delete a load balancer: The corresponding logs: The clouprovider config is: The Nodes are actually Azure VMs that belong to a VMO (aka vmss with flexible orchestration mode) - regular VMs and managed independently of the vmss. So those VMs are managed on Azure as . LoadBalancer deletion works with the very same setup with v1.21.1 of the in-tree Azure CCM. After recent cherry-picks, with v1.21.4 we observe the failure above. a cluster using VMs that belong to a VMO a Service of type LoadBalancer the Service of type LoadBalancer sure that the deletion fails with: Kubernetes version (use ): v1.21.4 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Gardener Network plugin and version (if this is a network-related bug): Others:
/assign /triage accepted

Discussion:
hostUpdates := make([]func() error, 0, len(ipConfigurationIDs)) nodeUpdates := make(map[vmssMetaInfo]map[string]compute.VirtualMachineScaleSetVM) <del> errors := make([]error, 0) </del> <ins> allErrs := make([]error, 0) </ins> for i := range ipConfigurationIDs { ipConfigurationID := ipConfigurationIDs[i]

} klog.Errorf("Failed to GetNodeNameByIPConfigurationID(%s): %v", ipConfigurationID, err) <del> errors = append(errors, err) </del> <ins> allErrs = append(allErrs, err) </ins> continue } nodeResourceGroup, nodeVMSS, nodeInstanceID, nodeVMSSVM, err := ss.ensureBackendPoolDeletedFromNode(nodeName, backendPoolID) if err != nil { <del> klog.Errorf("EnsureBackendPoolDeleted(%s): backendPoolID(%s) - failed with error %v", getServiceName(service), backendPoolID, err) errors = append(errors, err) </del> <ins> if !errors.Is(err, ErrorNotVmssInstance) { // Do nothing for the VMAS nodes. klog.Errorf("EnsureBackendPoolDeleted(%s): backendPoolID(%s) - failed with error %v", getServiceName(service), backendPoolID, err) allErrs = append(allErrs, err) } </ins> continue }

} // Fail if there are other errors. <del> if len(errors) > 0 { return utilerrors.Flatten(utilerrors.NewAggregate(errors)) </del> <ins> if len(allErrs) > 0 { return utilerrors.Flatten(utilerrors.NewAggregate(allErrs)) </ins> } // Ensure the backendPoolID is also deleted on VMSS itself.
Change:
<!-- 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 --In ipvs mode client traffic(UDP) to a pod behind LoadbalancerIP is blackholed after node having the pod is rebooted. The issue seems to be similar to the below iptable issue, since client continuously tries to connect to the loadbalancerIP (even before kubeproxy has applied all rules), and we see that stale conntracks entries remain even after rules are applied. After the stale conntrack entries are cleaned manually the traffic starts flowing : From the below code looks like ipvs currently clears stale conntrack entries for ExternalIPs but not LoadbalancerIP(?): ().String())-,for%20%2C%20extIP%20%3A%3D%20range%20svcInfo.ExternalIPStrings()%20%7B,-staleServices.Insert(extIP UDP traffic between client and pod(behind Loadbalancer IP) should have been established after node reboot. a POD acting as a UDP server and expose it through Loadbalancer service a UDP client to continuously send traffic to the LoadbalancerIP the node having the pod. after the new pod serving UDP is up, the UDP traffic from client would be blackholed(until stale conntrack entries are cleared). Kubernetes version (use ): 1.21.1 Cloud provider or hardware configuration: Manufacturer: Dell Inc. Product Name: PowerEdge R640 Version: Not Specified OS (e.g: ): SUSE Linux Enterprise Server 15 SP2 Kernel (e.g. ): Linux pool16-n108-wk16-n080 5.3.18-24.75.3..0.PTF.-default # 1 SMP Thu Sep 9 23:24:48 UTC 2021 () x8664 x8664 x8664 GNU/Linux Install tools: Network plugin and version (if this is a network-related bug): Calico v3.19.1-12- Others:
/sig network
/assign I'll try to reproduce this using but it may take some days.
yeah, ipvs kube-proxy doesn't have some of the latest "conntrack stale" fixes like , mainly because I'm not very familiar with IPVS and I can't know if all of them are needed or only some of them.
/triage accepted is it a matter of inserting externalIPs in conntrack?
No, when a node is rebootes and udp messages to a loadBalancerIP enters before kube-proxy is started, then invalid (UNREPLIED) conntrack entrys are created. They will black-hole traffic, and since traffic keeps coming they will never timeout. This is not easy to reproduce. I found it best to direct incoming traffic to a node (2), and have one endpoint pod on another node (4). Then reboot the node where traffic enters (and let the pod live) while traffic is sent continously. After reboot, check the conntrack on the rebooted node. In this example 3 out of 10 connections are ok. Those are the fortunate ones that didn't send a packet in the small time span from node start to kube-proxy start. (about 1 pkt/sec is sent on all 10 connections)
/area kube-proxy /area ipvs

Discussion:
for _, extIP := range svcInfo.ExternalIPStrings() { staleServices.Insert(extIP) } <ins> for _, extIP := range svcInfo.LoadBalancerIPStrings() { staleServices.Insert(extIP) } </ins> } }
Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --The unit test which was recently is flaking Sample failure error trace Full test report can be found The test is flaking because of the time mismatch in a condition and its observed that the while the control arrives some times its few milliseconds(8m19.997445973s) lesser than the expected time(8m20s) <!-- You can identify the SIG from the "prowjobconfigurl" on the testgrid dashboard for a test --
/assign
/sig api-machinery /kind flake A flake according to the job history: https://prow.ppc64le-
/cc who got the PR assigned /triage accepted

Discussion:
} func TestWithMaxWaitRateLimiter(t *testing.T) { <del> limiter := NewWithMaxWaitRateLimiter(DefaultControllerRateLimiter(), 500*time.Second) </del> <ins> limiter := NewWithMaxWaitRateLimiter(NewStepRateLimiter(5*time.Millisecond, 1000*time.Second, 100), 500*time.Second) </ins> for i := 0; i < 100; i++ { if e, a := 5*time.Millisecond, limiter.When(i); e != a { <del> t.Errorf("expected %v, got %v", e, a) </del> <ins> t.Errorf("expected %v, got %v ", e, a) </ins> } } <del> for i := 100; i < 5100; i++ { if e, a := 500*time.Second, limiter.When(i); e < a { </del> <ins> for i := 100; i < 200; i++ { if e, a := 500*time.Second, limiter.When(i); e != a { </ins> t.Errorf("expected %v, got %v", e, a) } } <ins> } </ins> <del> for i := 5100; i < 5200; i++ { if e, a := 500*time.Second, limiter.When(i); e != a { t.Errorf("expected %v, got %v", e, a) } </del> <ins> var _ RateLimiter = &StepRateLimiter{} func NewStepRateLimiter(baseDelay time.Duration, maxDelay time.Duration, threshold int) RateLimiter { return &StepRateLimiter{ baseDelay: baseDelay, maxDelay:  maxDelay, threshold: threshold, } } type StepRateLimiter struct { count     int threshold int baseDelay time.Duration maxDelay  time.Duration } func (r *StepRateLimiter) When(item interface{}) time.Duration { r.count += 1 if r.count <= r.threshold { return r.baseDelay </ins> } <ins> return r.maxDelay } func (r *StepRateLimiter) NumRequeues(item interface{}) int { return 0 } func (r *StepRateLimiter) Forget(item interface{}) { </ins> }
Change:
On a ppc64le host, fast build was failing: # make KUBEFASTBUILD=true quick-release +++ [0908 15:56:36] Verifying Prerequisites.... +++ [0908 15:56:36] Building Docker image kube-build:build--5-v1.23.0-go1.17-buster.0 +++ [0908 15:56:44] Syncing sources to container +++ [0908 15:56:48] Running build command... +++ [0908 15:56:56] Building go targets for linux/ppc64le: touch: cannot touch 'output/bin/prerelease-lifecycle-gen': No such file or directory make[2]: [Makefile.generatedfiles:209: output/bin/prerelease-lifecycle-gen] Error 1 make[1]: [Makefile:552: generatedfiles] Error 2 make: [Makefile:512: cross] Error 1 !!! [0908 15:56:58] Call tree: !!! [0908 15:56:58] 1: kube::build::runbuildcommandex(...) !!! [0908 15:56:58] 2: kube::build::runbuildcommand(...) make: [Makefile:454: quick-release] Error 1 This error happened because the output/bin/ directory didn't exist at the moment the file output/bin/prerelease-lifecycle-gen was touched, so the path didn't exist. The output/bin symlink was not created by kube::golang::placebins() because kube::golang::setupplatforms() assumed KUBECLIENT_PLATFORMS=linux/amd64 despite being on a ppc64le host.
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 release
looks like this is a missing feature and not a bug. /kind feature

Discussion:
elif [[ "${KUBE_FASTBUILD:-}" == "true" ]]; then host_arch=$(kube::util::host_arch) <del> if [[ "${host_arch}" != "amd64" && "${host_arch}" != "arm64" ]]; then # on any platform other than amd64 and arm64, we just default to amd64 </del> <ins> if [[ "${host_arch}" != "amd64" && "${host_arch}" != "arm64" && "${host_arch}" != "ppc64le" ]]; then # on any platform other than amd64, arm64 and ppc64le, we just default to amd64 </ins> host_arch="amd64" fi KUBE_SERVER_PLATFORMS=("linux/${host_arch}")
Change:
At , within the loop , variable is shared by all the loop iterations, as described in the Go specification (). All instances of &node within the loop may refer to the last node item updated by the loop. As a consequence, may hold multiple instances of the same node. Note that the following unit test checks only the number of nodes rather than the nodes themselves (otherwise the bug may be revealed): More information on the bug can be found at A fixe is to avoid reusing the shared variable : Found by #deepgo.
/triage accepted /area e2e-test-framework /sig testing
Thanks for pointing out, makes complete sense. I'm happy to fix it. /assign

Discussion:
framework.ExpectNoErrorWithOffset(0, err) for _, node := range nodeList.Items { if node.Labels[gkeNodepoolNameKey] == poolName { <ins> node := node </ins> nodes = append(nodes, &node) } }

} for _, pv := range allPVs.Items { if pv.Spec.StorageClassName == scName { <ins> pv := pv </ins> remainingPVs = append(remainingPVs, &pv) } }
Change:
At , within the loop , variable is shared by all the loop iterations, as described in the Go specification (). All instances of &pv within the loop may refer to the last tem updated by the loop. As a consequence, may hold multiple instances of the same item. Later on these remaining PVs are deleted, so it is possible that the same is deleted multiple times: More information on the bug can be found at A fix is to avoid reusing the shared variable node: Found by #deepgo.
/triage accepted /area e2e-test-framework
Thanks for pointing out, makes complete sense. I'm happy to fix it. /assign
/sig testing

Discussion:
framework.ExpectNoErrorWithOffset(0, err) for _, node := range nodeList.Items { if node.Labels[gkeNodepoolNameKey] == poolName { <ins> node := node </ins> nodes = append(nodes, &node) } }

} for _, pv := range allPVs.Items { if pv.Spec.StorageClassName == scName { <ins> pv := pv </ins> remainingPVs = append(remainingPVs, &pv) } }
Change:
says: It likely means not , but
/sig network /good-first-issue Thanks! TODO: Change to
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 : /sig network /good-first-issue Thanks! 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
/assign
/unassign
/triage accepted

Discussion:
before running <del> `kube init --config <path_to_configuration_file>` </del> <ins> `kubeadm init --config <path_to_configuration_file>` </ins> to specify the ipvs mode before deploying the cluster.