jiebi/CodeConvo huggingface dataset:
Code change:
"reason_cache.go", "runonce.go", "runtime.go", <ins> "time_cache.go", </ins> "util.go", "volume_host.go", ],

Related discussion:
text: These tests have flaked consistently since merged: in many cases, they are the only failure in a test run: Either the functionality introduced by that PR is not reliable, or the test is faulty. /sig node /priority critical-urgent /assign
/milestone v1.19
/assign
Looks like this is failing ~5% of pull-kubernetes-node-e2e runs
FYI
Looks like there might still be a race somewhere looking at the kubelet logs Success case: Fail case:
Looking at it more, it seems like is unexpectedly empty here Success: Fail:
Stacks of interest I think we might be dealing with a stale If there is a call before the container is to the Pod in the runtime and the is called within the 2 second default cache period, it seems possible that the in the could have no containers.
what do you think of this analysis? If so, any obvious solutions occur to you?
If I'm correct, didn't introduce this; just the e2e test exposed an existing bug in the kubelet.
That all looks correct. I'm taking a look at the proposed solutions
Code change:
} } <ins> func TestStringQuantityAsApproximateFloat64(t *testing.T) { table := []struct { in  string out float64 }{ {"2Ki", 2048}, {"1.1Ki", 1126.4e+0}, {"1Mi", 1.048576e+06}, {"2Gi", 2.147483648e+09}, } for _, item := range table { t.Run(item.in, func(t *testing.T) { in, err := ParseQuantity(item.in) if err != nil { t.Fatal(err) } out := in.AsApproximateFloat64() if out != item.out { t.Fatalf("expected %v, got %v", item.out, out) } if in.d.Dec != nil { if i, ok := in.AsInt64(); ok { q := intQuantity(i, 0, in.Format) out := q.AsApproximateFloat64() if out != item.out { t.Fatalf("as int quantity: expected %v, got %v", item.out, out) } } } }) } } </ins> func benchmarkQuantities() []Quantity { return []Quantity{ intQuantity(1024*1024*1024, 0, BinarySI),

Related discussion:
text: <!-- 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 --I found that for with returns a very small value. The value should be almost the same as the one of . My minimal : Result: While the top three lines () are good, the float values in the bottom three lines () might be broken. 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:
/sig api-machinery
/assign
/cc /triage accepted
Code change:
Subsystem:         KubeletSubsystem, Name:              AssignedConfigKey, Help:              "The node's understanding of intended config. The count is always 1.", <del> DeprecatedVersion: "1.23.0", </del> <ins> DeprecatedVersion: "1.22.0", </ins> StabilityLevel:    metrics.ALPHA, }, []string{ConfigSourceLabelKey, ConfigUIDLabelKey, ConfigResourceVersionLabelKey, KubeletConfigKeyLabelKey},

Related discussion:
text: This shipped in 1.22 as deprecated in 1.22. As a hacky fix to unbreak tests on 1.23 dev, I bumped the deprecation policy one release: We will need to revert that before 1.23 ships and figure out a better solution. /kind cleanup /milestone v1.23 /sig node
/triage accepted
I want to try it. Can I take this issue?
I have explained how to fix this on PR:
/reopen reverted in as fix did not work
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
/cc
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
Hi, Im the bug triage shadow. Since we're in 1.23 milestone code freeze, could we move this issue to milestone 1.24?
this is critical for 1.23 and I think it just got forgotten... we need to get this fixed before test freeze
/priority important-soon
Code change:
AllowExpandedDNSConfig bool // Allow invalid topologySpreadConstraint labelSelector for backward compatibility AllowInvalidTopologySpreadConstraintLabelSelector bool <ins> // Allow node selector additions for gated pods. AllowMutableNodeSelectorAndNodeAffinity bool </ins> } // validatePodMetadataAndSpec tests if required fields in the pod.metadata and pod.spec are set,

Related discussion:
text: See for context. This issue is creating to track work on the API validation changes. Validation relaxation of certain fields in the pod spec to allow for mutable scheduling directives.
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
/sig scheduling
Docs PR:
Code change:
# journal message level, 0 is debug KUBE_LOG_LEVEL=0 <ins> KUBE_ALLOW_PRIV="true" </ins> ``` * Start the appropriate services on fed1:

Related discussion:
text: https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
There are 3 different issues in this bug: high resource consumption (or too strict limits on our side) - should fix it to remove namespace: [I looked into it, and it was because events etcd didn't even come up in this test. The problem here is that we are not collecting logs from etcd in kubemark - I will send a PR fixing it later today hopefully. (that I didn't have time to look into yet).
So actually, the non-started events etcd was the pulling image problem: So we may want to retry in case of failures also.
The first one should be fixed by The second one will be fixed by The third problem is actually related to pod-nanny, which is frequently sending list requests to apiserver. It should be rewritten to use watch instead.
Since the main issue is fixed, I'm decreasing the priority.
For the third problem, I've just sent out: for review. Once that one is merged, we should build the new image and bump tags in our config files.
Code change:
# journal message level, 0 is debug KUBE_LOG_LEVEL=0 <ins> KUBE_ALLOW_PRIV="true" </ins> ``` * Start the appropriate services on fed1:

Related discussion:
text: https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
So the remaining things here to do are: kubernetes/contrib + update version of pod-nanny in heapster manifests tun kubemark-5 resource constraints
What we should also do, is to add "kubemark-scale" to list of non-blocking suites of merge-queue, so that bugs will be automatically filed for that suite.
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
There are three remaining things to do here: tweak limits for kubemark-5 merge add kubemark-scale to non-blocking suites of merge-queue can you please take care of the first one? I will take care of the other two.
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
It seems that this PR broke scalability: I'm reverting it and will try to debug it offline.
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
All the scalability failures from last day are because of - that PR was reverted, and I fixed the problem in and built a new image. (I did some 100-node cluster tests locally and it worked fine after the change).
Code change:
err = e2epod.WaitForPodNameRunningInNamespace(ctx, m.cs, pod.Name, pod.Namespace) framework.ExpectNoError(err, "Failed to start pod1: %v", err) <ins> pvc, err = m.cs.CoreV1().PersistentVolumeClaims(pvc.Namespace).Get(ctx, pvc.Name, metav1.GetOptions{}) if err != nil { framework.Failf("failed to get pvc %s, %v", pvc.Name, err) } gomega.Expect(pvc.Spec.VolumeName).ShouldNot(gomega.BeEquivalentTo(""), "while provisioning a volume for resizing") </ins> pv, err := m.cs.CoreV1().PersistentVolumes().Get(ctx, pvc.Spec.VolumeName, metav1.GetOptions{}) if err != nil { framework.Failf("failed to get pv %s, %v", pvc.Spec.VolumeName, err)

Related discussion:
text: Seen in pull-kubernetes-e2e-gce-cos-alpha-features Specific job failure
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
from the error message I don't know if it refers to the sig-storage error or to the sig-auth one
/sig storage
/kind failing-test
/assign From : ... I am not sure if it's related:
is the culprit. cannot be used inside a . This only gets caught when the test actually runs, otherwise Ginkgo never sees the incorrect .
I don’t understand why sometimes it can get the pv by namebut sometimes it failed
but then is a sig-auth test , not storage , sorry /sig auth this seems that was recently in
/remove sig-storage
/assign /priority important-soon
/unassign
is still failed. seems not fixing the whole problem. /reopen feel free to close if the ci is green.
Reopened this issue. <detailsIn response to : is still failed. /reopen feel free to close if the ci is green. 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
the failure now looks like it is just a sig storage issue:
cc
/assign looks like the new test is still an issue
I think this line is the problem: When the test creates the object, it may take time for the PV to be provisioned and to be bound to the PVC. So you should do another before this call so you can get the latest PVC object with the bound PV.
I opened to get PVC again before using .
Only do PersistentVolumeClaims.Get() is not enough, whether we need to wait for sometimes to wait it bound? because sometimes the testcase is successful and sometime is failed.
If the Pod was able to run, then the PVC has to be bound.
so I can't understand why sometimes the testcase is successful and sometimes is failed.
Code change:
err = e2epod.WaitForPodNameRunningInNamespace(ctx, m.cs, pod.Name, pod.Namespace) framework.ExpectNoError(err, "Failed to start pod1: %v", err) <ins> pvc, err = m.cs.CoreV1().PersistentVolumeClaims(pvc.Namespace).Get(ctx, pvc.Name, metav1.GetOptions{}) if err != nil { framework.Failf("failed to get pvc %s, %v", pvc.Name, err) } gomega.Expect(pvc.Spec.VolumeName).ShouldNot(gomega.BeEquivalentTo(""), "while provisioning a volume for resizing") </ins> pv, err := m.cs.CoreV1().PersistentVolumes().Get(ctx, pvc.Spec.VolumeName, metav1.GetOptions{}) if err != nil { framework.Failf("failed to get pv %s, %v", pvc.Spec.VolumeName, err)

Related discussion:
text: By default, the DelayBinding is false, it will wait for PVC bound during creation. This is weird.
It waits for the claim to be bound, but the test case still needs to refresh its pvc object.
Because of the refresh is async, so after the pvc was bound, we need to get the pvc again, isn't it?
Code change:
csiAttacher := attacher.(*csiAttacher) <del> go func(spec *volume.Spec, id, nodename string, fail bool) { </del> <ins> go func(spec *volume.Spec, nodename string, fail bool) { </ins> attachID, err := csiAttacher.Attach(spec, types.NodeName(nodename)) if !fail && err != nil { t.Errorf("expecting no failure, but got err: %v", err)

Related discussion:
text: <!-- 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: Followup to In 1.15, we can merge this commit: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/assign
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
Code change:
"k8s.io/kubernetes/pkg/apis/batch" "k8s.io/kubernetes/pkg/runtime" "k8s.io/kubernetes/pkg/types" <del> hashutil "k8s.io/kubernetes/pkg/util/hash" </del> ) // Utilities for dealing with Jobs and CronJobs and time.

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): Environment: Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Debian GNU/Linux 8 (jessie) Kernel (e.g. ): 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux What happened: Deployed a scheduled job from this manifest: After some time the jobs are no longer executed: What you expected to happen: Jobs are executed as defined in the manifest. How to reproduce it (as minimally and precisely as possible): Deploy a scheduled job and wait for some time.
Some logs from the controller manager:
Ping. More than 2 weeks and no action at all? Anything else i can do?
I'm also encountering this using both and as concurrency policies, fwiw.
I'm hitting this as well. Kube
Do the jobs start to reschedule if you delete old one? Try running . cc
From kube-controller-manager logs: The job is scheduled for 1:00. I think the "Multiple unmet start times" message is a clue of where things start going downhill. Also, notice how at 1:00 the controller wants to create job (for a whole day, it had failed on ).
Deleting (all) old jobs / pods fixes the problem temporarily. After some time the scheduled jobs face the same issue again.
There's a fix () that I've submitted against master to fix the Replace strategy, I'll mark it for inclusion in 1.4.
The other problem that I see here is this: It is possible that our is creating duplicates. I'll try to investigate that a bit more.
sorry for the delay in response time, I must have missed that while going through issues. Next time you're experiencing problems/have a question wrt Jobs/ScheduledJobs, just ping me directly in the issue.
No problem and I will. Thanks!
I'm still hitting this on
Fix in flight , I'll make sure to cherry-pick it back to 1.4
does this ship in to latest kubernetes release?
yes, this should be present in 1.5, 1.4 cherry-pick hasn't been merged yet.
so this issue is still present in v1.4.6?
Code change:
"k8s.io/kubernetes/pkg/apis/batch" "k8s.io/kubernetes/pkg/runtime" "k8s.io/kubernetes/pkg/types" <del> hashutil "k8s.io/kubernetes/pkg/util/hash" </del> ) // Utilities for dealing with Jobs and CronJobs and time.

Related discussion:
text: yes - it is still present there. My fix was merged to 1.4 yesterday. You should wait for the next 1.4.x release.
thanks!
which according to should happen Dec 8th.
any news on the release?
See !msg/kubernetes-dev/o0At2-4KKQ8/_kPVM1XyDAAJ
so v1.4.7 will be released on that same day?
Look like should be available later today: !msg/kubernetes-dev/00lJpT9pxDc/YZfDzCxMDQAJ
Code change:
close(monitor.stopCh) } } <ins> // reset monitors so that the graph builder can be safely re-run/synced. gb.monitors = nil </ins> glog.Infof("stopped %d of %d monitors", stopped, len(monitors)) }

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: https://k8s- 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:
/sig testing /area build-release
A lot of tests in are very flaky. From and , and are the top 3 flaky tests among all kubernetes tests. /assign
fix double close channel panic related to https://k8s-
Is this issue ready to be closed? Did that PR fix the reason for flakes in all these tests?
This is still a problem, these tests are still the flakiest https://k8s-
My fix is double close channel panic. This one is not fixed. May be I shoud edit the title.
we also need a new issue then, I'm a bit overloaded ATM could one of open a new one with the garbagecollector failures?
OK
I'll try to debug some of these.
I created a new issue
Thanks!
Code change:
pod := newTestPodForQuota(podName, requests, api.ResourceList{}) pod, err = f.Client.Pods(f.Namespace.Name).Create(pod) Expect(err).NotTo(HaveOccurred()) <ins> podToUpdate := pod </ins> By("Ensuring ResourceQuota status captures the pod usage") usedResources[api.ResourceQuotas] = resource.MustParse("1")

Related discussion:
text: The scenario that presented a problem was the following: a) create pods in a namespace that do not make a memory claim b) add a quota that tracks memory c) update one of the pods previously created by reducing its active deadline. Expected result: Since a pod cannot change its resources via update, we should have been allowed to update the pod spec. Actual Result: error since the pod did not make a memory claim, quota rejects the pod.
cc
Code change:
} } <ins> func TestUpdatePodForTerminatedRuntimePod(t *testing.T) { podWorkers, processed := createPodWorkers() now := time.Now() podWorkers.podSyncStatuses[types.UID("1")] = &podSyncStatus{ startedTerminating: true, terminatedAt:       now.Add(-time.Second), terminatingAt:      now.Add(-2 * time.Second), gracePeriod:        1, } // creates synthetic pod podWorkers.UpdatePod(UpdatePodOptions{ UpdateType: kubetypes.SyncPodKill, RunningPod: &kubecontainer.Pod{ID: "1", Name: "1", Namespace: "test"}, }) drainAllWorkers(podWorkers) if len(processed) != 0 { t.Fatalf("Not all pods processed: %v", processed) } updates := processed["1"] if len(updates) != 0 { t.Fatalf("unexpected updates: %v", updates) } if len(podWorkers.lastUndeliveredWorkUpdate) != 0 { t.Fatalf("Unexpected undelivered work") } } </ins> func TestUpdatePodDoesNotForgetSyncPodKill(t *testing.T) { podWorkers, processed := createPodWorkers() numPods := 20

Related discussion:
text: <!-- 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 --When testing against OpenShift CI, I discovered a panic in the kubelet: Further investigation revealed that it is possible for to panic under certain circumstances: We hit this case when (podStatus remains nil) and (nil will be passed along to ). I'm not sure why exactly that would happen but it seems possible. Don't panic! Unclear, I've been trying to trace the code/find evidence of this happening in k8s CI but haven't found a match yet. ( would be nice :smile:) /sig node /cc /priority important-soon /milestone v1.22 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:
/triage accepted
/assign
The bug is that running pods should terminate and then stop, not move to terminated. So something is getting into terminated but should never be in any other work type than terminating. We'll need more debug to determine why but I suspect that an orphaned pod is still in podSyncStatus at the time it UpdatePod is called, which means it's not seen as being in Terminating. isRuntimePod forces podSyncStatus to be a certain state, but perhaps it's should resett a terminated bool. Asked elana to add a v4 min level in the test jobs that reproduced this so we can see.
has bumped, here's a v=4 log with a panic: https://gcsweb-
Elana got the version with more logs and it is indeed the case that the pod is terminating (in this case because a CSI volume hasn't been torn down).