jiebi/CodeConvo huggingface dataset:
Change:
pvs := make([]*v1.PersistentVolume, maxPVs) for i := 0; i < maxPVs; i++ { // This PV will be claimed, released, and deleted <del> pvs[i] = createPV("pv-"+strconv.Itoa(i), "/tmp/foo"+strconv.Itoa(i), strconv.Itoa(i)+"G", </del> <ins> pvs[i] = createPV("pv-"+strconv.Itoa(i), "/tmp/foo"+strconv.Itoa(i), strconv.Itoa(i+1)+"G", </ins> []v1.PersistentVolumeAccessMode{v1.ReadWriteOnce}, v1.PersistentVolumeReclaimRetain) }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG REPORT /kind bug What happened: If someone requests a zero (0) capacity PVC and an administrator creates a zero (0) capacity PV, Kubernetes will happily bind them together. Unfortunately, any use of this PVC/PV combination by a pod will fail. It fails because the zero capacity PV cannot be formatted or mounted successfully. Note: The same issue happens for dynamically provisioned PVs. What you expected to happen: I expect that Kubernetes would not allow creation of invalid PVC and PV objects, aka zero (0) capacity PVs and PVCs. How to reproduce it (as minimally and precisely as possible): Create a pod that requests a zero capacity PVC, using dynamic PV provisioning is simpler than creating your own zero (0) capacity PV. The pod will fail to reach a running state, since the related PV fails to be formatted and mounted successfully. Here is the error that I received for a test I performed requesting a zero capacity PVC using ceph rbd: Anything else we need to know?: Here is a related item with a specific fix for external ceph rbd provisioner: Environment: Nothing specific to environment
/sig storage
/assign
Change:
continue } if strings.ToUpper(*size.Name) == vmsize { <del> klog.V(2).Infof("got a matching size in getMaxDataDiskCount, Name: %s, MaxDataDiskCount: %d", *size.Name, *size.MaxDataDiskCount) </del> <ins> klog.V(12).Infof("got a matching size in getMaxDataDiskCount, Name: %s, MaxDataDiskCount: %d", *size.Name, *size.MaxDataDiskCount) </ins> return int64(*size.MaxDataDiskCount) } }

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!--What happened: There are too many logs in GetVolumeLimits on azure disk, which would flush kubelet logs, it happens every 10 seconds: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug /assign /sig azure
Change:
// Volume information is extracted from the directory structure: // (ROOT_DIR)/(POD_ID)/volumes/(VOLUME_KIND)/(VOLUME_NAME) for _, podIDDir := range podIDDirs { <ins> if !podIDDir.IsDir() { continue } </ins> podID := podIDDir.Name() podIDPath := path.Join(mountPath, podID, "volumes") volumeKindDirs, err := ioutil.ReadDir(podIDPath)

Discussion:
This error appears every 10 seconds (with .bashlogout & .bashprofile also), when set up with vagrant: Aug 12 23:16:58 kubernetes-minion-1 kubelet[]: E0812 23:16:58. ] Could not read directory: , (open not a directory) This is because the kubelet root directory defaults to /var/lib/kubelet, which is also the homedir for the kubelet user, and so the user's default files trip up kubelet. Manually deleting the files (rm *) causes the errors to stop without any obvious ill-effects.
fixed in
Change:
func (ev *Evaluator) prepareCandidate(ctx context.Context, c Candidate, pod *v1.Pod, pluginName string) *framework.Status { fh := ev.Handler cs := ev.Handler.ClientSet() <del> for _, victim := range c.Victims().Pods { </del> <ins> ctx, cancel := context.WithCancel(ctx) defer cancel() errCh := parallelize.NewErrorChannel() preemptPod := func(index int) { victim := c.Victims().Pods[index] </ins> // If the victim is a WaitingPod, send a reject message to the PermitPlugin. // Otherwise we should delete the victim. if waitingPod := fh.GetWaitingPod(victim.UID); waitingPod != nil {

Discussion:
When a pod requires preempting more than one pod, this happens sequentially. It should be done in parallel. /sig scheduling /sig scalability Preemption happens in the scheduling cycle, meaning that no other scheduling attempts happen while preemption is ongoing, hurting throughput. An alternative is to the deletes in a separate routine, like we do for binding.
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
I'm a newbie, may I have a try at this proposal?
Yes, this is a good candidate for new contributors. However, I would like to hear from SIG scalability whether there are any concerns about this.
Parallelizing the loops looks like the easier option to implement, but deleting in a separate routine will likely offer the better throughput for the average case.
Parallelizing loops seems fine from SIG Scalability perspective - we already do something similar for example in KCM when creating pods or in scheduler each binding is done by separate goroutine. One question though, is there a limit of pods that we want to preempt here? 100 parallel calls will be probably fine, but 1000 wouldn't be most likely.
We only preempt pods from a single node, so that's a natural threshold. And we have a parallelizing mini-library that has 16 workers by default.
Hi, do you still want to work on this one?
YesIt's still under discussion.
So we can use the parallelizing mini-library to do this?
You can use this parallelizer we defined in scheduler framework directly.
feel free to take it by writing on a comment.
/assign
Change:
epIpt := netlinktest.ExpectedIptablesChain{ string(kubeServicesChain): {{ JumpChain: string(KubeLoadBalancerChain), MatchSet: kubeLoadBalancerSet, <ins> }, { JumpChain: string(KubeMarkMasqChain), MatchSet: kubeClusterIPSet, }, { JumpChain: string(KubeNodePortChain), MatchSet: "", }, { JumpChain: "ACCEPT", MatchSet: kubeClusterIPSet, }, { JumpChain: "ACCEPT", MatchSet: kubeLoadBalancerSet, </ins> }}, string(kubeLoadBalancerSet): {{ JumpChain: string(KubeMarkMasqChain), MatchSet: "",

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 --ipvs mode didn't preserve client IP for NodePort Service with protocol SCTP and ExternalTrafficPolicy Local. iptables mode works fine. ipvs mode with TCP and UDP protocol works fine. Client IP for NodePort Service should be preseved when ExternalTrafficPolicy is Local regardless of the mode and the protocol. kube-proxy mode to ipvs a NodePort service with protocol SCTP and ExternalTrafficPolicy Local the NodePort service, the client IP was not preserved This is caused by wrong order of iptables rules that match kubeNodePortLocalSetSCTP and kubeNodePortSetSCTP: Kubernetes version (use ): v1.22.0 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:
/sig network /assign
/triage accepted
Change:
StartedInitContainersErrorCount int64 } <ins> // ensurePodsStatsOnNode returns a boolean after checking Pods statistics on a particular node func ensurePodsStatsOnNode(ctx context.Context, c clientset.Interface, namespace, nodeName string, statsChecked *bool) (bool, error) { nodeStats, err := e2ekubelet.GetStatsSummary(ctx, c, nodeName) framework.ExpectNoError(err, "Error getting node stats") for _, podStats := range nodeStats.Pods { if podStats.PodRef.Namespace != namespace { continue } // check various pod stats if *podStats.CPU.UsageCoreNanoSeconds <= 0 { framework.Logf("Pod %s/%s stats report cpu usage equal to %v but should be greater than 0", podStats.PodRef.Namespace, podStats.PodRef.Name, *podStats.CPU.UsageCoreNanoSeconds) return false, nil } if *podStats.Memory.WorkingSetBytes <= 0 { framework.Logf("Pod %s/%s stats report memory usage equal to %v but should be greater than 0", podStats.PodRef.Namespace, podStats.PodRef.Name, *podStats.CPU.UsageCoreNanoSeconds) return false, nil } for _, containerStats := range podStats.Containers { *statsChecked = true // check various container stats if *containerStats.CPU.UsageCoreNanoSeconds <= 0 { framework.Logf("Container %s stats report cpu usage equal to %v but should be greater than 0", containerStats.Name, *containerStats.CPU.UsageCoreNanoSeconds) return false, nil } if *containerStats.Memory.WorkingSetBytes <= 0 { framework.Logf("Container %s stats report memory usage equal to %v but should be greater than 0", containerStats.Name, *containerStats.Memory.WorkingSetBytes) return false, nil } if *containerStats.Logs.UsedBytes <= 0 { framework.Logf("Container %s stats log usage equal to %v but should be greater than 0", containerStats.Name, *containerStats.Logs.UsedBytes) return false, nil } } } return true, nil } </ins> // getCurrentHostProcessMetrics returns a HostPRocessContainersMetrics object. Any metrics that do not have any // values reported will be set to 0. func getCurrentHostProcessMetrics(ctx context.Context, f *framework.Framework, nodeName string) (HostProcessContainersMetrics, error) {

Discussion:
ci-kubernetes-e2e-capz-master-containerd-windows Kubernetes e2e suite: [It] [sig-windows] [Feature:WindowsHostProcessContainers] [MinimumKubeletVersion:1.22] HostProcess containers container stats validation feb 8th 2023 reading of the log is showing reporting zero It looks like the pod had started up just as it check the failure on the test. Adding a retry or a longer wait might make the test more reliable /sig windows
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
Change:
github.com/containerd/go-runc => github.com/containerd/go-runc v0.0.0-20180907222934-5a6d9f37cfa3 github.com/containerd/ttrpc => github.com/containerd/ttrpc v1.0.2 github.com/containerd/typeurl => github.com/containerd/typeurl v1.0.1 <del> github.com/containernetworking/cni => github.com/containernetworking/cni v0.8.0 </del> <ins> github.com/containernetworking/cni => github.com/containernetworking/cni v0.8.1 </ins> github.com/coredns/corefile-migration => github.com/coredns/corefile-migration v1.0.11 github.com/coreos/bbolt => github.com/coreos/bbolt v1.3.2 github.com/coreos/etcd => github.com/coreos/etcd v3.3.13+incompatible

Discussion:
is identified with with severity rating as high. This is found using snyk scan while running against k/k master We're not using directly however, it gets tagged for vulnerability scans as we use . The fix is already present in and we can bump the dep. Bump dep to which has the mentioned CVE fix. and check Kubernetes version (use ): n/a Cloud provider or hardware configuration: any OS (e.g: ): n/a Kernel (e.g. ): n/a Install tools: n/a Network plugin and version (if this is a network-related bug): n/a Others: n/a /sig architecture /area code-organization for the dependency
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
Change:
logEntryMessageRegex = regexp.MustCompile("(?:Id+ d+:d+:d+.d+       d+ logs_generator.go:67] )?(d+) .*") ) <del> // Type to track the progress of logs generating pod type loggingPod struct { // Name of the pod Name string // Cache of ingested and read entries Occurrences map[int]logEntry // Number of lines expected to be ingested from this pod ExpectedLinesNumber int } </del> type logEntry struct { Payload string } <ins> func (entry logEntry) getLogEntryNumber() (int, bool) { submatch := logEntryMessageRegex.FindStringSubmatch(entry.Payload) if submatch == nil || len(submatch) < 2 { return 0, false } lineNumber, err := strconv.Atoi(submatch[1]) return lineNumber, err == nil } </ins> type logsProvider interface { Init() error Cleanup()

Discussion:
Pods should be run in parallel with checking the logs from the backend to fit into the timeout.
Change:
"File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated "+ "after server cert). If HTTPS serving is enabled, and --tls-cert-file and "+ "--tls-private-key-file are not provided, a self-signed certificate and key "+ <del> "are generated for the public address and saved to /var/run/kubernetes.") </del> <ins> "are generated for the public address and saved to the directory specified by --cert-dir.") </ins> fs.StringVar(&s.ServerCert.CertKey.KeyFile, "tls-private-key-file", s.ServerCert.CertKey.KeyFile, "File containing the default x509 private key matching --tls-cert-file.")

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Not all variants of api servers store the TLS cert files at /var/run/kubernetes. After the commit was merged back in Feb, some variants such as kube-aggregator stores them at '', but the hard-coded help message still says it will save the keys and certs generated into /var/run/kubernetes. What you expected to happen: Either we refactor the code so the help message prints an accurate location, or we change the help message to make it always true. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: No. Environment: Kubernetes version (use ): at least 1.7 and above Cloud provider or hardware configuration**: N/A OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A
/sig api-machinery
pls help confirm.
We should make the messages accurate.
/assign
GitHub didn't allow me to assign the following users: jennybuckley. Note that only can be assigned. <detailsIn response to : /assign 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
/cc
Change:
framework.ExpectNoError(err, "Fluentd deployed incorrectly") By("Running synthetic logger") <del> pod := createLoggingPod(f, podName, "", 10*60, 10*time.Minute) </del> <ins> pod := startNewLoggingPod(f, podName, "", 10*60, 10*time.Minute) </ins> defer f.PodClient().Delete(podName, &meta_v1.DeleteOptions{}) err = framework.WaitForPodNameRunningInNamespace(f.ClientSet, podName, f.Namespace.Name) framework.ExpectNoError(err, fmt.Sprintf("Should've successfully waited for pod %s to be running", podName))

Discussion:
Pods should be run in parallel with checking the logs from the backend to fit into the timeout.
Change:
framework.Logf("Deleting Gluster endpoints %q...", name) err := cs.CoreV1().Endpoints(ns.Name).Delete(name, nil) if err != nil { <del> framework.Failf("Gluster delete endpoints failed: %v", err) </del> <ins> if !errors.IsNotFound(err) { framework.Failf("Gluster delete endpoints failed: %v", err) } framework.Logf("Gluster endpoints %q not found, assuming deleted", name) </ins> } framework.Logf("Deleting Gluster server pod %q...", g.serverPod.Name) err = framework.DeletePodWithWait(f, cs, g.serverPod)

Discussion:
Failing on gke only: https://k8s- https://k8s-
/assign
Unfortunately the exact error message that its failing with is lost due to a typo: I have fixed that typo locally and am running the tests repeatedly to try to reproduce the flake. have been unable to reproduce the flake on HEAD of Kubernetes in GKE in 15 runs so far. Running 150 tests overnight.
Unable to repro on my own GKE cluster. Merged the error message fix, will monitor for the next flake to debug more
Change:
kube::test::get_object_assert 'rc busybox1' "{{$rc_replicas_field}}" '1' # Command output_message=$(! kubectl scale --current-replicas=1 --replicas=2 -f hack/testdata/recursive/rc --recursive 2>&1 "${kube_flags[@]}") <del> # Post-condition: busybox0 & busybox replication controllers are scaled to 2 # replicas, and since busybox2 is malformed, it should error </del> <ins> # Post-condition: busybox0 & busybox1 replication controllers are scaled to 2 replicas, and since busybox2 is malformed, it should error </ins> kube::test::get_object_assert 'rc busybox0' "{{$rc_replicas_field}}" '2' kube::test::get_object_assert 'rc busybox1' "{{$rc_replicas_field}}" '2' kube::test::if_has_string "${output_message}" "Object 'Kind' is missing"

Discussion:
cc
Assigning to per test-
Flaked again
The flake actually happened when pausing the deployment. Changing issue title.
When , sometimes one of the deployments isn't paused. cc
I can't access the internal Google logs to examine the cause, nor can I reproduce this issue locally. Is there any additional information that you can provide to help troubleshoot the flake?
I've gone ahead and attempted a fix for this in
We should fix this in eventually
the external links are here ():
Change:
kube::test::get_object_assert pods "{{range.items}}{{$id_field}}:{{end}}" '' kube::test::if_has_string "${output_message}" "Object 'Kind' is missing" <del> ### Rollback a deployment </del> <ins> ### Rollout on multiple deployments recursively </ins> # Pre-condition: no deployments exist kube::test::get_object_assert deployment "{{range.items}}{{$id_field}}:{{end}}" '' # Command

Discussion:
cc
Assigning to per test-
Flaked again
The flake actually happened when pausing the deployment. Changing issue title.
When , sometimes one of the deployments isn't paused. cc
I can't access the internal Google logs to examine the cause, nor can I reproduce this issue locally. Is there any additional information that you can provide to help troubleshoot the flake?
I've gone ahead and attempted a fix for this in
We should fix this in eventually
the external links are here ():
Change:
// restarted. status = pod.Status } <del> if status.Phase == v1.PodFailed || status.Phase == v1.PodSucceeded { return true } return false </del> <ins> return status.Phase == v1.PodFailed || status.Phase == v1.PodSucceeded || (pod.DeletionTimestamp != nil && notRunning(status.ContainerStatuses)) </ins> } // OkToDeletePod returns true if all required node-level resources that a pod was consuming have

Discussion:
https://k8s- Only one green run out of the past 11 runs. Potential offenders: /cc (saw you guys discussed this on sig-node slack)
Related test failures: , ,
assigning this to you. and I can help out if necessary.
Still not sure what's going on. In 1 downward api modification failure, I saw a pod created, container started, container killed 1 second later by the kubelet, when it's supposed to run for 120s. Very strange.
See e.g.
So far I've only found the volume tests failing in the ubuntu trusty docker 1.10 vms. Not sure if that's 100% of them or just what I've looked at so far.
One idea is that cgroups are cleaned up before the pod is started, and that somehow causes the pod to fail. See . I'll try to verify my theory later...
That's consistent with my observation. Ubuntu+docker 1.10 seems to be the only one failing. If anyone wants to try reproducing this locally, this would be the image to use.
I noticed that too. The "pod ran to completion" is "pod started and immediately exited". I've tried to reproduce locally and can't find a commit around last Wednesday that obviously would have caused this. I'll post any information I find here.
I tried to reproduce locally (not on GCE) with trusty & docker 1.10 but the tests are all passing so far. Either I didn't wait long enough or it's something specific to the GCE trusty image being used.
-- i am not sure how that is possible. the odd bit to me is we ran w/ pod cgroups on in node e2e since 1.5 if i am not mistaken.
-- ignore my previous comment as previously we only deleted the cgroup when the pod was removed from the api server, and not just terminated. so yeah, its possible something is happening here...
maybe we need to pass in both activePods and runningPods to get a more accurate listing?
see from . Search for pod , which has cgroups cleaned up within 2 seconds of starting. May not be the culplit, but its worth looking into.

the runningPods cache appears like it could have a 2 second latency before updating its cache so it could be related and could be helped by passing in activePods as well...
see:
That is possible. I am also not sure when a pod is considered running, and in what order pods are created. Do we create cgroups before starting the container? Would a pod be returned by GetPods (from above comment) if it had cgroups set up, but the container wasn't running yet? It could also simply be that we are cleaning up a pod's cgroups before it is ever running (if that is possible based on above questions).
-- we create the cgroup before the container is started, so I think we need to pass activePods. see:
Change:
--quiet  --delete-disks boot  --zone "${ZONE}"  <del> "${minions[@]::10}" || true </del> <ins> "${minions[@]::10}" </ins> minions=( "${minions[@]:10}" ) done

Discussion:
'kubernetes-soak-weekly-deploy' sometimes fails to deploy because the clean-up cluster step fails to delete the template: Then the subsequent cluster step fails to create the template, because it already exists: It keeps retrying and failing, because the template already exists, until it times out and the deployment fails. Suggested fixes: Cluster down should try harder to delete the template (maybe wait/retry). Cluster up should recognize that the template exists, and try to delete/recreate, or just re-use the existing.
Looks like ran in to this on Monday, May 11, 2015 around 1:00 PM PST. I'll assign this to my self and take a crack at fixing it.
This is causing most of our e2e tests to fail in continuous integration as well as users private e2e test clusters. Bumping to priority/p0 and v1.0 milestone. Saad thinks he's figured it out, and is working on a fix as we speak.
In essence... Saad: "I think what's happening is the previous clean up step to delete the managed instance group happens asynchronously, therefore there is a race condition to delete the template. Working on a fix".
Change:
"!('k3' in self.val1)", "self.val1 == {'k1': 'a', 'k2': 'b'}", }, <ins> errors: map[string]string{ // Mixed type maps are not allowed since we have HomogeneousAggregateLiterals enabled "{'k1': 'a', 'k2': 1, 'k2': false}": "expected type 'string' but found 'int'", }, </ins> }, {name: "objects", obj: map[string]interface{}{

Discussion:
Added this test to : this resulted in: The test should pass. Add the above test No response All versions where CEL is used. All Doesn't matter No response No response No response_
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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
Opened to discuss the expected behavior in cel-go for this.