jiebi/CodeConvo huggingface dataset:
Change:
says: ... My understanding is, that is not anymore correct. The correct snippet would be:
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 network
/remove-kimd bug /kind cleanup
/remove-kind bug (typo in previous comment)
/assign

Discussion:
### Cluster Created by Kubeadm <del> If you are using kubeadm with a [configuration file](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file), you have to add `mode: ipvs` below the `kubeProxy` field as part of the kubeadm configuration. </del> <ins> If you are using kubeadm with a [configuration file](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file), you have to add mode: ipvs in a KubeProxyConfiguration (separated by -- that is also passed to kubeadm init). </ins> ```yaml ... <del> kubeProxy: config: mode: ipvs </del> <ins> apiVersion: kubeproxy.config.k8s.io/v1alpha1 kind: KubeProxyConfiguration mode: ipvs </ins> ... ```
Change:
node-kubelet-serial Kubelet should correctly account for terminated pods after restart Since test was created, flakes 10-20% of the time. Not entirely clear why, I haven't looked. No response /assign /sig node
Introduced by , maybe we should use to replace See the log below, a pod becomes Succeed may exhaust tens of seconds
/triage accepted
Yeah I only tested this locally and not in CI, it seems that in CI the pods take much longer. Timings just need to be tweaked.
/reopen still a number of flakes since the attached PR merged, I don't think that 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
from this link, I see all suites passed, which flakes do you mean?
I see this failure in
so this problem should have been fixed by
From gubernator: In all cases, it's timing out. I'll try upping the startTimeout.
/reopen still flaking
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
Luckily the kubelet log is clear as to what's going on. From (flake ) The test should work fine if we drop the CPU request a bit, let me tweak it to make up for the possible extra 100m scheduled. I'm not sure what's causing that (aren't these tests serial? what the heck is getting scheduled) but we should be resilient to it. Also, needs to be fixed. This test will no longer detect the regression it was designed to show after that change. I will revert it and also fix the resource requirements and that should fix this test.
/milestone v1.23 need to fix this before test freeze

Discussion:
createBatchPodWithRateControl(f, restartNeverPods, podCreationInterval) defer deletePodsSync(f, restartNeverPods) <del> completedPods := waitForPods(f, podCountRestartNever, time.Minute) </del> <ins> completedPods := waitForPods(f, podCountRestartNever, startTimeout) </ins> if len(completedPods) < podCountRestartNever { framework.Failf("Failed to run sufficient restartNever pods, got %d but expected %d", len(completedPods), podCountRestartNever) }

// restart may think these old pods are consuming CPU and we // will get an OutOfCpu error. ginkgo.By("verifying restartNever pods succeed and restartAlways pods stay running") <del> for start := time.Now(); time.Since(start) < startTimeout; time.Sleep(10 * time.Second) { postRestartRunningPods := waitForPods(f, numAllPods, time.Minute) if len(postRestartRunningPods) < numAllPods { framework.Failf("less pods are running after node restart, got %d but expected %d", len(postRestartRunningPods), numAllPods) } </del> <ins> postRestartRunningPods := waitForPods(f, numAllPods, startTimeout) if len(postRestartRunningPods) < numAllPods { framework.Failf("less pods are running after node restart, got %d but expected %d", len(postRestartRunningPods), numAllPods) </ins> } }) })
Change:
node-kubelet-serial Kubelet should correctly account for terminated pods after restart Since test was created, flakes 10-20% of the time. Not entirely clear why, I haven't looked. No response /assign /sig node
Introduced by , maybe we should use to replace See the log below, a pod becomes Succeed may exhaust tens of seconds
/triage accepted
Yeah I only tested this locally and not in CI, it seems that in CI the pods take much longer. Timings just need to be tweaked.
/reopen still a number of flakes since the attached PR merged, I don't think that 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
from this link, I see all suites passed, which flakes do you mean?
I see this failure in
so this problem should have been fixed by
From gubernator: In all cases, it's timing out. I'll try upping the startTimeout.
/reopen still flaking
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
Luckily the kubelet log is clear as to what's going on. From (flake ) The test should work fine if we drop the CPU request a bit, let me tweak it to make up for the possible extra 100m scheduled. I'm not sure what's causing that (aren't these tests serial? what the heck is getting scheduled) but we should be resilient to it. Also, needs to be fixed. This test will no longer detect the regression it was designed to show after that change. I will revert it and also fix the resource requirements and that should fix this test.
/milestone v1.23 need to fix this before test freeze

Discussion:
podCount            = 100 podCreationInterval = 100 * time.Millisecond recoverTimeout      = 5 * time.Minute <del> startTimeout        = 3 * time.Minute </del> <ins> startTimeout        = 5 * time.Minute </ins> // restartCount is chosen so even with minPods we exhaust the default // allocation of a /24. minPods      = 50

// restart may think these old pods are consuming CPU and we // will get an OutOfCpu error. ginkgo.By("verifying restartNever pods succeed and restartAlways pods stay running") <del> postRestartRunningPods := waitForPods(f, numAllPods, startTimeout) </del> <ins> postRestartRunningPods := waitForPods(f, numAllPods, recoverTimeout) </ins> if len(postRestartRunningPods) < numAllPods { framework.Failf("less pods are running after node restart, got %d but expected %d", len(postRestartRunningPods), numAllPods) }
Change:
should implement . This ensures that it's use as value in a key/value pair emits a struct and not the string. /ref
This depends on logr 1.2.0, which will be in /wg structure-logging /sig instrumentation
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : This depends on logr 1.2.0, which will be in /sig instrumentation 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
I'd like to work on this :) /assign
/wg structured-logging
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale /lifecycle frozen

Discussion:
func (n NamespacedName) String() string { return n.Namespace + string(Separator) + n.Name } <ins> // MarshalLog emits a struct containing required key/value pair func (n NamespacedName) MarshalLog() interface{} { return struct { Name, Namespace string }{ Name:      n.Name, Namespace: n.Namespace, } } </ins>

"go.uber.org/zap" "go.uber.org/zap/zapcore" <ins> "k8s.io/apimachinery/pkg/types" </ins> logsapi "k8s.io/component-base/logs/api/v1" )

format:     "{"ts":%f,"caller":"json/json_test.go:%d","msg":"test for duplicate keys","v":0,"akey":"avalue","akey":"anothervalue"}n", keysValues: []interface{}{"akey", "avalue", "akey", "anothervalue"}, }, <ins> { msg:        "test for NamespacedName argument", format:     "{"ts":%f,"caller":"json/json_test.go:%d","msg":"test for NamespacedName argument","v":0,"obj":{"Name":"kube-proxy","Namespace":"kube-system"}}n", keysValues: []interface{}{"obj", types.NamespacedName{Name: "kube-proxy", Namespace: "kube-system"}}, }, </ins> } for _, data := range testDataInfo {
Change:
I would like to propose the graduation of the metric from alpha to stable. The metric has been stable for 2 years now.
/sig api-machinery /sig instrumentation
I am willing to do all StabilityLevels from alpha to stable? Is that right?
/assign
- The request is to have the stability level for the metric graduate to stable. If there are other metrics you want to do at the same time that's a bonus, but not part of the request in this issue.
/sig node /remove-sig api-machinery /cc
To be promoted to stable, the metrics would need to be renamed from to in order to follow Prometheus best practices as well as sig-instrumentation naming guidelines.
/cc
/assign
/triage accepted

Discussion:
zoneSizeKey             = "zone_size" zoneNoUnhealthyNodesKey = "unhealthy_nodes_in_zone" evictionsNumberKey      = "evictions_number" <ins> evictionsTotalKey       = "evictions_total" </ins> ) var (

) evictionsNumber = metrics.NewCounterVec( &metrics.CounterOpts{ <ins> Subsystem:         nodeControllerSubsystem, Name:              evictionsNumberKey, Help:              "Number of Node evictions that happened since current instance of NodeController started, This metric is replaced by node_collector_evictions_total.", DeprecatedVersion: "1.24.0", StabilityLevel:    metrics.ALPHA, }, []string{"zone"}, ) evictionsTotal = metrics.NewCounterVec( &metrics.CounterOpts{ </ins> Subsystem:      nodeControllerSubsystem, <del> Name:           evictionsNumberKey, </del> <ins> Name:           evictionsTotalKey, </ins> Help:           "Number of Node evictions that happened since current instance of NodeController started.", <del> StabilityLevel: metrics.ALPHA, </del> <ins> StabilityLevel: metrics.STABLE, </ins> }, []string{"zone"}, )

legacyregistry.MustRegister(zoneSize) legacyregistry.MustRegister(unhealthyNodes) legacyregistry.MustRegister(evictionsNumber) <ins> legacyregistry.MustRegister(evictionsTotal) </ins> }) }

//count the evictionsNumber zone := nodetopology.GetZoneKey(node) evictionsNumber.WithLabelValues(zone).Inc() <ins> evictionsTotal.WithLabelValues(zone).Inc() </ins> } return result, 0

if node != nil { zone := nodetopology.GetZoneKey(node) evictionsNumber.WithLabelValues(zone).Inc() <ins> evictionsTotal.WithLabelValues(zone).Inc() </ins> } return true, 0

// Init the metric for the new zone. klog.Infof("Initializing eviction metric for zone: %v", zone) evictionsNumber.WithLabelValues(zone).Add(0) <ins> evictionsTotal.WithLabelValues(zone).Add(0) </ins> } }

<ins> - name: evictions_total subsystem: node_collector help: Number of Node evictions that happened since current instance of NodeController started. type: Counter stabilityLevel: STABLE labels: - zone </ins> - name: framework_extension_point_duration_seconds subsystem: scheduler help: Latency for running all plugins of a specific extension point.
Change:
[X] Two weeks soak end date: Nov 18 According to this APIsnoop query, there are still a remaining Service endpoint which is untested. A service resource didn&rsquo;t support endpoint until was merged. Create a watch to track service events Create a service with a static label. Confirm via the watch that the service was created. Delete the service via the service with the dynamic client with . Confirm via the watch that the service was deleted. The above steps have been implemented in the follwing . This query shows all the endpoints hit within a short period of running the above e2e test If a test with these calls gets merged, test coverage will go up by 1 point This test is also created with the goal of conformance promotion. /sig testing /sig network /area conformance
/triage accepted
Waiting on 2 week soak before promoting the test to conformance /reopen
Reopened this issue. <detailsIn response to : Waiting on 2 week soak before promoting the test to conformance /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

Discussion:
action MUST be validated. release: v1.21 file: test/e2e/network/service.go <ins> - testname: Service, deletes a collection of services codename: '[sig-network] Services should delete a collection of services [Conformance]' description: Create three services with the required labels and ports. It MUST locate three services in the test namespace. It MUST succeed at deleting a collection of services via a label selector. It MUST locate only one service after deleting the service collection. release: v1.23 file: test/e2e/network/service.go </ins> - testname: Find Kubernetes Service in default Namespace codename: '[sig-network] Services should find a service from listing all namespaces [Conformance]'

framework.Logf("Service %s deleted", testSvcName) }) <del> ginkgo.It("should delete a collection of services", func() { </del> <ins> /* Release: v1.23 Testname: Service, deletes a collection of services Description: Create three services with the required labels and ports. It MUST locate three services in the test namespace. It MUST succeed at deleting a collection of services via a label selector. It MUST locate only one service after deleting the service collection. */ framework.ConformanceIt("should delete a collection of services", func() { </ins> ns := f.Namespace.Name svcClient := f.ClientSet.CoreV1().Services(ns)
Change:
/kind feature Hey, in K8s 1.23 we are planning to deprecate multiple klog flags. Deprecated flags: , , , , , , , , , , , One of the alpha milestones is requires us to remove usage of deprecated flags within K8s repo. Examples found for kubemark [x] [x] [x] [x] Recommendation, either: Stop depending on writing to files and remove flags , or Add go-runner to kubemark image and migrate to /sig scalability /wg structured-logging
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
Resolved in both k/k and kubernetes-sigs/cloud-provider-azure. /close

Discussion:
<ins> FROM scratch ADD hello / EXPOSE 8080 ENTRYPOINT ["/hello"] </ins>

<ins> package main import ( "fmt" "net/http" ) func helloFromKubernetes(w http.ResponseWriter, r *http.Request) { fmt.Fprintln(w, "Hello World! -- Kubernetes") } func main() { http.HandleFunc("/", helloFromKubernetes) err := http.ListenAndServe(":8080", nil) if err != nil { panic("ListenAndServe: " + err.Error()) } } </ins>

<ins> #!/bin/bash set -e set -x CGO_ENABLED=0 go build  -a -ldflags '-extldflags "-static" -s' hello.go </ins>
Change:
everything with is now failing, likely after 2021-11-04 17:44 PDT 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
The best course of actions is likely just remove those tests from the job, similar to

Discussion:
if err != nil { framework.Failf("Failed to list all dns service pods") } <del> if len(dnsPods.Items) != 1 { framework.Failf("Unexpected number of pods (%d) matches the label selector %v", len(dnsPods.Items), dnsServiceLabelSelector.String()) </del> <ins> if len(dnsPods.Items) < 1 { framework.Failf("No pods match the label selector %v", dnsServiceLabelSelector.String()) </ins> } framework.ExpectNoError(framework.WaitForPodRunningInNamespace(f.Client, dnsPods.Items[0].Name, api.NamespaceSystem)) }
Change:
I install kubernetes 1.22.2 calico 3.20.2 centos 8.4 kernel 4.18 when I create some pod,and sawed that kubelet status had some error my node and pod are all running Is this a bug of 1.22.2 Can any one help me to resolv this problem,thanks! kubelet had PLEG Write status error I installed the service in 3 hours No response No response No response /sig
/remove-kind failing-test /sig node /kind support
In this pr , the log level was changed from Info to Error, may cause some confusion. /cc
/triage accepted
Is there a problem with this log message? Or is there no problem with that?
Yeah, there's no problem
But when I delete all the pods, I got some error kubelet log: did you know Do you know what the problem is : Error getting node" err="node "" not found"
ignore Flag --network-plugin has been deprecatedbecause i use kubernetes 1.22.2 and docker 20.10.10Docker is no longer officially recommended
You should see the actual realtime logs by "journalctl -f -u kubelet.service"
I restart kubelet,and use command "journalctl -f -u kubelet.service" . the log "Error getting node" err="node "" not found" is gone ! when i check my docker.service ,I get this : ! it doesn't have any error about docker.
Is that still a problem ?
I think there are no real errors in there. I think we should only log them if there is an error. /assign
/remove-kind support /kind bug
/retitle Kubelet logging PLEG: Write status error when no errors have occured

Discussion:
// GetPodStatus(pod *kubecontainer.Pod) so that Docker can avoid listing // all containers again. status, err := g.runtime.GetPodStatus(pod.ID, pod.Name, pod.Namespace) <del> if klog.V(6).Enabled() { klog.V(6).ErrorS(err, "PLEG: Write status", "pod", klog.KRef(pod.Namespace, pod.Name), "podStatus", status) </del> <ins> if err != nil { if klog.V(6).Enabled() { klog.V(6).ErrorS(err, "PLEG: Write status", "pod", klog.KRef(pod.Namespace, pod.Name), "podStatus", status) } else { klog.V(4).ErrorS(err, "PLEG: Write status", "pod", klog.KRef(pod.Namespace, pod.Name)) } </ins> } else { <del> klog.V(4).ErrorS(err, "PLEG: Write status", "pod", klog.KRef(pod.Namespace, pod.Name)) } if err == nil { </del> <ins> if klog.V(6).Enabled() { klog.V(6).InfoS("PLEG: Write status", "pod", klog.KRef(pod.Namespace, pod.Name), "podStatus", status) } else { klog.V(4).InfoS("PLEG: Write status", "pod", klog.KRef(pod.Namespace, pod.Name)) } </ins> // Preserve the pod IP across cache updates if the new IP is empty. // When a pod is torn down, kubelet may race with PLEG and retrieve // a pod status after network teardown, but the kubernetes API expects
Change:
As a user if I a custom API resource (for example, a Fischer from the sample-apiserver), I can change the name in the metadata and I do not get a . Instead, a Patch to the new user-edited name is created, which can result in NotFound or even making changes to the wrong object. If I the object and change the metadata name (or kind or apiVersion), then it should be rejected by kubectl and no Patch performed. Run the sample-apiserver, and create a new object with name . Then do , and change the metadata name to , and save. You will either see a item not found (if test2 does not already exist), or you will accidentally edit . Slack discussion here: <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 CLI

Discussion:
import ( "bufio" "bytes" <ins> "encoding/json" </ins> "errors" "fmt" "io"

klog.V(4).Infof("Unable to calculate diff, no merge is possible: %v", err) return err } <ins> var patchMap map[string]interface{} err = json.Unmarshal(patch, &patchMap) if err != nil { klog.V(4).Infof("Unable to calculate diff, no merge is possible: %v", err) return err } </ins> for _, precondition := range preconditions { <del> if !precondition(patch) { </del> <ins> if !precondition(patchMap) { </ins> klog.V(4).Infof("Unable to calculate diff, no merge is possible: %v", err) return fmt.Errorf("%s", "At least one of apiVersion, kind and name was changed") }