jiebi/CodeConvo huggingface dataset:
Change:
// 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

Discussion:
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
Change:
return } <ins> // truncatePodHostnameIfNeeded truncates the pod hostname if it's longer than 63 chars. func truncatePodHostnameIfNeeded(podName, hostname string) (string, error) { // Cap hostname at 63 chars (specification is 64bytes which is 63 chars and the null terminating char). const hostnameMaxLen = 63 if len(hostname) <= hostnameMaxLen { return hostname, nil } truncated := hostname[:hostnameMaxLen] glog.Errorf("hostname for pod:%q was longer than %d. Truncated hostname to :%q", podName, hostnameMaxLen, truncated) // hostname should not end with '-' or '.' truncated = strings.TrimRight(truncated, "-.") if len(truncated) == 0 { // This should never happen. return "", fmt.Errorf("hostname for pod %q was invalid: %q", podName, hostname) } return truncated, nil } </ins> // GeneratePodHostNameAndDomain creates a hostname and domain name for a pod, // given that pod's spec and annotations or returns an error. func (kl *Kubelet) GeneratePodHostNameAndDomain(pod *api.Pod) (string, string, error) { // TODO(vmarmol): Handle better. <del> // Cap hostname at 63 chars (specification is 64bytes which is 63 chars and the null terminating char). </del> clusterDomain := kl.clusterDomain <del> const hostnameMaxLen = 63 </del> podAnnotations := pod.Annotations if podAnnotations == nil { podAnnotations = make(map[string]string)

Discussion:
Docker daemon complains "invalid hostname format" if the truncated host name ends with "." The truncation occurs .
Docker checks hostname with the regexp (See ): It means that the hostname must end with an alnum, not or . This issue has been here for a long time. This usually happens to static pod, because we compose a looooong name for static pod. We didn't hit this just because we are lucky. :P Will send a PR to fix this. /cc
: Needed for v1.5? please add milestone if so
Thanks for reminding. :) This is a bug fix in kubelet. Mark 1.5. /cc
Are you working on a fix?
Yeah, the fix is here
Change:
Persist(map[string]string) error } <ins> type noopPersister struct{} func (n *noopPersister) Persist(_ map[string]string) error { // no operation persister return nil } </ins> // All registered auth provider plugins. var pluginsLock sync.Mutex var plugins = make(map[string]Factory)

Discussion:
<!-- 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 --What happened: What you expected to happen: no panicking How to reproduce it (as minimally and precisely as possible): use azure or OIDC auth plugin with a or without a Anything else we need to know?: a similar OIDC panic issue is registered here
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 auth

Using with a without a () will result in a panic. What happened: What you expected to happen: Expected a successful kube-api server call, or at the very least an error to be returned. Although i think it should just not call and continue with the kube-api server call. Anything else we need to know?: The reason for this is due to where has no check.
/sig cli
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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
Change:
<del> v1.31.0-go1.23rc2-bullseye.0 </del> <ins> v1.31.0-go1.22.5-bullseye.0 </ins>

Discussion:
sgtm, add an issue labeled as release-blocking and in the milestone to either promote to 1.23.0 or revert this to 1.22.x before our 1.31 release Originally posted by in Kubernetes is being built and tested with go1.23rc2 at HEAD () to let it bake in the CI and help iron out issues, if any, with this version of Go. However, for the 1.31 release, the version of Go should be a non-rc, released version. The release timeline of go1.23.0 is ~same as the release timeline of K8s 1.31.0 (see ). If go1.23.0 is not out by then, we should revert to go1.22.x before cutting K8s 1.31.0. /sig release architecture /area code-organization /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
/triage accepted /cc
/milestone v1.31
cc
xposting relevant slack thread:
Also unlike in the past, missing shipping 1.23.0 in 1.31.0 is not a big deal, we have much more room to switch to 1.23.0 in a patch release after all the compat changes with the go team. So we should not fear reverting if the timelines don't line up.
(though go1.23 adds the thing that makes it workable to default to old go version compat settings, so we'll have to eke out another 5 months on 1.21/1.22 for until we can adopt 1.23 on release branches in ~Jan if we miss 1.31, but that's how it looks like it will have to happen)
Change:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips tallclair </del> <ins> pwittrock seans3 soltysh </ins>

Discussion:
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the sample-cli-plugin repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig cli

The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the cli-runtime repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig cli
Change:
<ins> # 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. TAG ?= e2e PREFIX ?= gcr.io/k8s-testimages all: push image: docker build --pull -t $(PREFIX)/redis:$(TAG) . push: image gcloud docker -- push $(PREFIX)/redis:$(TAG) clean: </ins>

Discussion:
Kubernetes version (use ): master What happened: Pulling the redis image takes a while, like 30 seconds in GCE. This might be leading to periodic timeouts in tests like . What you expected to happen: Tests shouldn't depend on large images that take a potentially long time to pull. proposed fix to reduce flakiness we can increase the replica count on this test to 2 or make the redis image we use smaller (or not use redis at all and just use a simpler smaller image)
cc (considering this as a bug since we shouldnt need a 500MG image just to test kubectl :))
This should be as simple as changing the current to use alpine and install redis, instead of basing it off debian, installing gcc, and compiling redis from source :-) The image should be ~10MB.
Change:
}, } for k, v := range errorCases { <del> if errs := validateContainers(v, volumeDevices, field.NewPath("field")); len(errs) == 0 { </del> <ins> if errs := validateContainers(v, false, volumeDevices, field.NewPath("field")); len(errs) == 0 { t.Errorf("expected failure for %s", k) } } } func TestValidateInitContainers(t *testing.T) { volumeDevices := make(map[string]core.VolumeSource) capabilities.SetForTests(capabilities.Capabilities{ AllowPrivileged: true, }) successCase := []core.Container{ { Name:  "container-1-same-host-port-different-protocol", Image: "image", Ports: []core.ContainerPort{ {ContainerPort: 80, HostPort: 80, Protocol: "TCP"}, {ContainerPort: 80, HostPort: 80, Protocol: "UDP"}, }, ImagePullPolicy:          "IfNotPresent", TerminationMessagePolicy: "File", }, { Name:  "container-2-same-host-port-different-protocol", Image: "image", Ports: []core.ContainerPort{ {ContainerPort: 80, HostPort: 80, Protocol: "TCP"}, {ContainerPort: 80, HostPort: 80, Protocol: "UDP"}, }, ImagePullPolicy:          "IfNotPresent", TerminationMessagePolicy: "File", }, } if errs := validateContainers(successCase, true, volumeDevices, field.NewPath("field")); len(errs) != 0 { t.Errorf("expected success: %v", errs) } capabilities.SetForTests(capabilities.Capabilities{ AllowPrivileged: false, }) errorCases := map[string][]core.Container{ "duplicate ports": { { Name:  "abc", Image: "image", Ports: []core.ContainerPort{ { ContainerPort: 8080, HostPort: 8080, Protocol: "TCP", }, { ContainerPort: 8080, HostPort: 8080, Protocol: "TCP", }, }, ImagePullPolicy:          "IfNotPresent", TerminationMessagePolicy: "File", }, }, } for k, v := range errorCases { if errs := validateContainers(v, true, volumeDevices, field.NewPath("field")); len(errs) == 0 { </ins> t.Errorf("expected failure for %s", k) } }

Discussion:
I found that kubelet will not allocate hostports specified from initContainers. And PodFitsHostPorts in kube-scheduler does not take initContainer into consideration. Also, kube-apiserver think such pod is illegal, but I think it OK. We should make the behavior of spec.HostPorts in initContainer clear
/sig node
Exactly. I think this makes sense. Since initContainers are expected to be completed, we should not expose extra port mappings during creating pod sandbox, which may bring in security risks.
Sounds good to me.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Change:
) cidrSize := netutils.RangeSize(cidr) <del> if cidrSize < min { </del> <ins> // available addresses are always less than the cidr size // A /28 CIDR returns 16 addresses, but 2 of them, the network // and broadcast addresses are not available. if cidrSize <= min { </ins> return 0 }

Discussion:
kube-apiserver observed a panic: kube-apiserver should not panic Not sure yet -- will add more details as I investigate. No response v1.25.4 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
/sig network /cc
max is greater than offset?
/assign
Change:
// Logout calls SessionManager.Logout for the given connection. func (connection *VSphereConnection) Logout(ctx context.Context) { <del> m := session.NewManager(connection.Client) </del> <ins> clientLock.Lock() c := connection.Client clientLock.Unlock() if c == nil { return } m := session.NewManager(c) </ins> hasActiveSession, err := m.SessionIsActive(ctx) if err != nil {

Discussion:
What happened: Data race in tests in an unrelated PR Logs https://k8s- /kind bug /area platform/vsphere /area cloudprovider /sig cloud-provider
/kind flake
Another time it flaked in an unrelated PR https://k8s-
bringing this to your attention as a vsphere dev.
/assign
Looks like the race was in Feb 2017 here: But that code path wasn't covered by go test until vcsim support was here: I'll work on a fix.
Change:
. "github.com/onsi/gomega" ) <del> func isRestartNeverMirrorPod(p *api.Pod) bool { </del> <ins> func isNotRestartAlwaysMirrorPod(p *api.Pod) bool { </ins> if !kubepod.IsMirrorPod(p) { return false } <del> return p.Spec.RestartPolicy == api.RestartPolicyNever </del> <ins> return p.Spec.RestartPolicy != api.RestartPolicyAlways </ins> } func filterIrrelevantPods(pods []*api.Pod) []*api.Pod { var results []*api.Pod for _, p := range pods { <del> if isRestartNeverMirrorPod(p) { </del> <ins> if isNotRestartAlwaysMirrorPod(p) { </ins> // Mirror pods with restart policy == Never will not get // recreated if they are deleted after the pods have // terminated. For now, we discount such pods.

Discussion:
The restart test is broke by The original issue is The reason is We fixed this by filtering out mirror pod in the test. However changed to which broke the workaround. A quick fix is to filter out non-RestartAlways pods. Because either or pods could succeed, and we can not deal with terminated mirror pods very well now. /cc
Yeah... I see there's a number of problems here. I looked at the history of the image puller config and it looked to me that it was 'Never' from the beginning... Thanks for the fix though.
is this a release blocker for 1.5? Please update the issue ASAP, thanks! cc:
Change:
args = append(args, "-j", "DNAT", "--to-destination", net.JoinHostPort(proxyIP.String(), strconv.Itoa(proxyPort))) return args } <ins> func isTooManyFDsError(err error) bool { return strings.Contains(err.Error(), "too many open files") } </ins>

Discussion:
Restarting might also be acceptable. It's a pretty painful user experience right now if this happens-- it fills the logs with this message.
Yes, it should just panic() , Daniel Smith wrote:
Yeah I guess if it's out of FDs it can't really open a network connection to file an event...
kube-proxy should send an event when it starts up, just like kubelet does with its method. This works around the fact that you can't send an event when you are out of FDs, and it still provides a lot of debugging value.
Agreed with 1) kube-proxy should panic when hitting out of fd 2) restarted kube-proxy should pick up the crash reason like what we do for internal agent 3) crash reason should be propogated to upstream as an event.
Moving to the right sig.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/lifecycle frozen
/remove-lifecycle stale
/area kube-proxy
we're going to close this because, after 3 years or so , decreasing interest in the userspace proxy and nobody other then some openshift folks, are using the linux kube proxy .. can reopen if necessary ping :)
/close
Closing this issue. <detailsIn response to : /close 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
Change:
source /run/flannel/subnet.env source /etc/default/docker <del> echo DOCKER_OPTS="${DOCKER_OPTS} -H tcp://127.0.0.1:4243 -H unix:///var/run/docker.sock  </del> <ins> echo DOCKER_OPTS=" -H tcp://127.0.0.1:4243 -H unix:///var/run/docker.sock  </ins> --bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU}" > /etc/default/docker sudo service docker restart }

Discussion:
Kubernetes version (use ): 1.3.7 Environment: Cloud provider or hardware configuration: Bare-metal Ubuntu cluster OS (e.g. from /etc/os-release): Ubuntu 14.04.3 LTS Kernel (e.g. ): 3.19.0-47-generic Install tools: KUBERNETESPROVIDER=ubuntu ./kube- Others: Docker version 1.12.1 What happened: appends the same copy of each time we start and stop Kubernetes cluster (using Ubuntu's & ). For example, if we start Kubernetes cluster the first time and restart it again, the content of is doubled: This cause the following error when starting Kubernetes as seen in : What you expected to happen: content should not be concatenated every time Kubernetes is restarted. How to reproduce it (as minimally and precisely as possible): Start Kubernetes, stop it, and start it again, using and . Anything else do we need to know: One possible fix is to remove the in the following line in :
This is a bug and easy to fix. I'll open a PR to fix it
Bug has been fixed.
Change:
} func autoConvert_v1alpha1_DebuggingConfiguration_To_config_DebuggingConfiguration(in *DebuggingConfiguration, out *config.DebuggingConfiguration, s conversion.Scope) error { <del> out.EnableProfiling = in.EnableProfiling out.EnableContentionProfiling = in.EnableContentionProfiling </del> <ins> if err := v1.Convert_Pointer_bool_To_bool(&in.EnableProfiling, &out.EnableProfiling, s); err != nil { return err } if err := v1.Convert_Pointer_bool_To_bool(&in.EnableContentionProfiling, &out.EnableContentionProfiling, s); err != nil { return err } </ins> return nil } func autoConvert_config_DebuggingConfiguration_To_v1alpha1_DebuggingConfiguration(in *config.DebuggingConfiguration, out *DebuggingConfiguration, s conversion.Scope) error { <del> out.EnableProfiling = in.EnableProfiling out.EnableContentionProfiling = in.EnableContentionProfiling </del> <ins> if err := v1.Convert_bool_To_Pointer_bool(&in.EnableProfiling, &out.EnableProfiling, s); err != nil { return err } if err := v1.Convert_bool_To_Pointer_bool(&in.EnableContentionProfiling, &out.EnableContentionProfiling, s); err != nil { return err } </ins> return nil }

Discussion:
What would you like to be : Change the external DebuggingConfiguration member variables to pointer types. Why is this needed: So that we can set their default values to something different from golang's, for example enable profiling by default. /sig api-machinery /cc
The label(s) cannot be applied. These labels are supported: <detailsIn response to : What would you like to be : Change the external DebuggingConfiguration member variables to pointer types. Why is this needed: So that we can set their default values to something different from golang's, for example enable profiling by default. /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
done in