jiebi/CodeConvo huggingface dataset:
Code change:
assert.Len(fakeRuntime.ImageList, 1) } <ins> func TestDeleteUnusedImagesLimitByImageLiveTime(t *testing.T) { ctx := context.Background() mockCtrl := gomock.NewController(t) defer mockCtrl.Finish() mockStatsProvider := statstest.NewMockProvider(mockCtrl) manager, fakeRuntime := newRealImageGCManager(ImageGCPolicy{ MinAge: time.Second * 3, // set minAge to 3 seconds, }, mockStatsProvider) fakeRuntime.ImageList = []container.Image{ makeImage(0, 1024), makeImage(1, 2048), makeImage(2, 2048), } fakeRuntime.AllPodList = []*containertest.FakePod{ {Pod: &container.Pod{ Containers: []*container.Container{ makeContainer(2), }, }}, } // start to detect images manager.Start() // try to delete images, but images are not old enough,so no image will be deleted err := manager.DeleteUnusedImages(ctx) assert := assert.New(t) require.NoError(t, err) assert.Len(fakeRuntime.ImageList, 3) // sleep 3 seconds, then images will be old enough to be deleted time.Sleep(time.Second * 3) err = manager.DeleteUnusedImages(ctx) require.NoError(t, err) assert.Len(fakeRuntime.ImageList, 1) } </ins> func TestFreeSpaceRemoveByLeastRecentlyUsed(t *testing.T) { ctx := context.Background() mockCtrl := gomock.NewController(t)

Related discussion:
text: when kubelet restart,all images which notused cleaned. but there is a flag in kubelet,,explainMinimum age for an unused image before it is garbage collected. Examples: '300ms', '10s' or '2h45m'. i set to ,it's means if a image not used,it will live 20m and then clean by kubeletif has disk pressure.if kubelet not restart, it work,but if restart ther is a bug, not work,image will be cleaneven if it's no enough time. work, image even if not used,it will live 20m and then clean by kubelet. 1make node trigger disk pressure. 2pull some image which not used by pod 3restart kubelet 4image cleaned by kubelet after around 10s i see the source code, and maybe there is a bug. in func,well detect image and update firstdetect time for every image. and in func,well check images livetime by firstDetected. if kubelet running normal,it work,because there is a func. in this line,,in first time,ts is zero. so image's firstDetected time is zero,and in freeSpace this check is always false,so image will be cleaned. maybe we can change to ,can fix this bug. <details</details<detailsNone </details<details</details<details</details<details</details<details</details
/sig node
/assign
/triage accepted /priority backlog initial assessment of priority, subject to change
Code change:
codecs := serializer.NewCodecFactory(scheme) o := NewObjectTracker(scheme, codecs.UniversalDecoder()) w, err := o.Watch(testResource, "test_namespace") <ins> if err != nil { t.Fatalf("test resource watch failed in test_namespace: %v", err) } </ins> wAll, err := o.Watch(testResource, "") <ins> if err != nil { t.Fatalf("test resource watch failed in all namespaces: %v", err) } </ins> go func() { err := o.Create(testResource, testObj, ns) assert.NoError(t, err, "test resource creation failed")

Related discussion:
text: What happened: What you expected to happen: I am not sure if is it a bug, I think we should catch err when Watch testResource failed in func TestWatchCallNonNamespace. 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:
Absolutely we should check err gracefully.
/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
/fixes it
Code change:
newPod("non-matching-owned-0-", "node-0", simpleDaemonSetLabel2, ds), newPod("non-matching-orphan-1-", "node-1", simpleDaemonSetLabel2, nil), newPod("matching-owned-by-other-0-", "node-0", simpleDaemonSetLabel, ds2), <del> func() *v1.Pod { pod := newPod("matching-owned-2-but-set-for-deletion", "node-2", simpleDaemonSetLabel, ds) now := metav1.Now() pod.DeletionTimestamp = &now return pod }(), </del> } for _, pod := range ignoredPods { manager.podStore.Add(pod)

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: The DaemonSet controller will schedule a pod on a node when the old pod is still in Terminating state. This breaks the expectation that only one pod will be running at a time per node. What you expected to happen: The DaemonSet controller should not let two pods running at the same time on the same node. How to reproduce it (as minimally and precisely as possible): Create a DaemonSet. Set terminationGracePeriodSeconds to be relatively long. Kill a pod. Watch a new pod start on the same node when the old pod is still terminating. Anything else we need to know?: Seems this behavior was introduced in Environment: Kubernetes version (use ): 1.7.2 Cloud provider or hardware configuration**: GKE OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig apps
/cc
cc
cc: I think the expected behavior is correct, the terminating pod could be performing an important step such as 'removing a lock' or 'cleanup' etc., we should allow that to gracefully die before creating a new one. IMHO we should revoke to old behavior, but why did we need this new behavior in the first place? That is not clear to me from the PR and Issue.
We don't currently guarantee at least or at most one scheduling for DaemonSet. Both behaviors are under consideration via issue and in the future work section of the . The reason for is to "Make sure that controllers are not adopting children that are marked for deletion" (). This is necessary for GC to work properly.
Well the behavior may be technically undefined, but can I request that in the future changes like this be mentioned in the release notes?
Yes, certainly.
Code change:
newPod("non-matching-owned-0-", "node-0", simpleDaemonSetLabel2, ds), newPod("non-matching-orphan-1-", "node-1", simpleDaemonSetLabel2, nil), newPod("matching-owned-by-other-0-", "node-0", simpleDaemonSetLabel, ds2), <del> func() *v1.Pod { pod := newPod("matching-owned-2-but-set-for-deletion", "node-2", simpleDaemonSetLabel, ds) now := metav1.Now() pod.DeletionTimestamp = &now return pod }(), </del> } for _, pod := range ignoredPods { manager.podStore.Add(pod)

Related discussion:
text: Also "The DaemonSet controller should not let two pods running at the same time on the same node." is not necessarily the same thing as respecting termination prior to launching a new Pod. The former implies a more strict requirement than the latter. I think we should consider at least attempting to wait for a terminating Pod to be deleted prior to creating another Pod on the Node for same DaemonSet as default behavior.
will something like work then?
Code change:
if err != nil { return nil, fmt.Errorf("Error creating listener: %q", err) } <del> addTagsInput.ResourceArns = append(addTagsInput.ResourceArns, targetGroupArn) </del> <ins> resourceArns = append(resourceArns, targetGroupArn) </ins> } // Add tags to targets <ins> targetGroupTags := make([]*elbv2.Tag, 0, len(tags)) </ins> for k, v := range tags { <del> addTagsInput.Tags = append(addTagsInput.Tags, &elbv2.Tag{ </del> <ins> targetGroupTags = append(targetGroupTags, &elbv2.Tag{ </ins> Key: aws.String(k), Value: aws.String(v), }) } <del> if len(addTagsInput.ResourceArns) > 0 && len(addTagsInput.Tags) > 0 { _, err = c.elbv2.AddTags(addTagsInput) if err != nil { return nil, fmt.Errorf("Error adding tags after creating Load Balancer: %q", err) </del> <ins> if len(resourceArns) > 0 && len(targetGroupTags) > 0 { // elbv2.AddTags doesn't allow to tag multiple resources at once for _, arn := range resourceArns { _, err = c.elbv2.AddTags(&elbv2.AddTagsInput{ ResourceArns: []*string{arn}, Tags:         targetGroupTags, }) if err != nil { return nil, fmt.Errorf("Error adding tags after creating Load Balancer: %q", err) } </ins> } } } else {

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: We created a LoadBalancer service with type 'nlb' with two listeners forwarding traffic on two different ports. The service was created correctly along with the target groups and was functionning correctly. Around 20 hours later, no traffic was flowing from clients to any k8s nodes. While troubleshooting we discovered that the k8s node instance security group was lacking the input rules allowing traffic to the node ports for this LB. We deleted the service and recreated it. The service started working normally again, but we found out that the two target groups were missing their k8s tags. The logs contain the following error: What you expected to happen: We expected the NLB target groups to have k8s tags, so that k8s could remember it created them. How to reproduce it (as minimally and precisely as possible): Create a k8s service with NLB: Add a simple deployment that is matched by this service. Anything else we need to know?: Looking at AWS cloudtrail we could see the following error event: So the API request was called with two Resource ARNs, which is confirmed by the code: Since we have two target groups, there are two resources to tag. Except that the AWS API while allowing to send more than one resource ARNs doesn't allow it returning a validation error. This could be solved by doing one per target groups. Note that this can't happen on a Classic LB because there's no target groups.
Code change:
if err != nil { return nil, fmt.Errorf("Error creating listener: %q", err) } <del> addTagsInput.ResourceArns = append(addTagsInput.ResourceArns, targetGroupArn) </del> <ins> resourceArns = append(resourceArns, targetGroupArn) </ins> } // Add tags to targets <ins> targetGroupTags := make([]*elbv2.Tag, 0, len(tags)) </ins> for k, v := range tags { <del> addTagsInput.Tags = append(addTagsInput.Tags, &elbv2.Tag{ </del> <ins> targetGroupTags = append(targetGroupTags, &elbv2.Tag{ </ins> Key: aws.String(k), Value: aws.String(v), }) } <del> if len(addTagsInput.ResourceArns) > 0 && len(addTagsInput.Tags) > 0 { _, err = c.elbv2.AddTags(addTagsInput) if err != nil { return nil, fmt.Errorf("Error adding tags after creating Load Balancer: %q", err) </del> <ins> if len(resourceArns) > 0 && len(targetGroupTags) > 0 { // elbv2.AddTags doesn't allow to tag multiple resources at once for _, arn := range resourceArns { _, err = c.elbv2.AddTags(&elbv2.AddTagsInput{ ResourceArns: []*string{arn}, Tags:         targetGroupTags, }) if err != nil { return nil, fmt.Errorf("Error adding tags after creating Load Balancer: %q", err) } </ins> } } } else {

Related discussion:
text: I believe that those missing tags on the target groups are the root cause of the deletion of the security group rules allowing traffic to reach the nodeports, with this (hypothetical and unproved) scenario: 8s creates the target groups, the NLB, the listeners, the sg input rules 8s fails to tag the target groups, but doesn't rollback anything a subsequent convergence loops, k8s notices that there are two k8s-managed Security Group input rules, but those don't match any Target Groups or match Target Groups that are not managed by k8s (because they don't have the owner tags) 8s deletes those rules Unfortunately we don't see the rule deletion in the controller manager logs, but it appears in Cloudtrail: Let me know if you have any questions, Environment: Kubernetes version: 1.10.7 Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): CoreOS 1967.3.0 Kernel (e.g. ): Linux 4.14.88-coreos Install tools: home grown Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
/sig aws /assign
Hi, the root cause of your problem should already be solved by It's cherry-picked into old versions and available as v1.11.7, v1.12.5 and v1.13.3(hasn't released yet)
, Thanks, you're most certainly right about the root cause of the issue being . It indeed looks exactly like what we've experienced. Still there's the problem of target groups not being tagged.
Code change:
}) } }) <del> ginkgo.Context("CSI online volume expansion with secret[Feature:CSINodeExpandSecret]", func() { </del> <ins> ginkgo.Context("CSI online volume expansion with secret", func() { </ins> var stringSecret = map[string]string{ "username": "admin", "password": "t0p-Secret",

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:
}) } }) <del> ginkgo.Context("CSI online volume expansion with secret[Feature:CSINodeExpandSecret]", func() { </del> <ins> ginkgo.Context("CSI online volume expansion with secret", func() { </ins> var stringSecret = map[string]string{ "username": "admin", "password": "t0p-Secret",

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:
"//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/fields:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/labels:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//staging/src/k8s.io/client-go/kubernetes/fake:go_default_library", "//staging/src/k8s.io/client-go/testing:go_default_library",

Related discussion:
text: What happened: A Pod was scheduled for deletion because a taint w/ effect was observed in the Node the Pod was assigned to, and after the taint is removed from the Node, the Pod scheduled deletion isn't canceled. After scheduling pod deletion, the only cancels pod deletion if all taints are removed from the node, including any taints that the user relies on for their use-cases (example below). What you expected to happen: After the taint that triggered scheduling pod deletion is removed, cancels the scheduled pod deletion. How to reproduce it (as minimally and precisely as possible): A node is tainted w/ , so any workloads already assigned to it which don't tolerate this taint are evicted. A pod is created w/ tolerations: w/ unspecified and w/ . is assigned to . At some point in time after the previous steps took place, is tainted as . gets an update event for and observes two taints. It proceeds to calculate the minimum time (in seconds) that tolerates for the two taints which at this point is 300 seconds, and marks for deletion in ~300 seconds - this happens in-memory, in a timed-queue. At some point in time after the previous steps took place, and before the 300 seconds trigger happen, taint is removed from . gets an update event for and observes only one taint, . It proceeds to calculate the minimum time (in seconds) that tolerates for the this taint which is infinity, and returns, not canceling the previous deletion. It completely ignores the fact that the taint that triggered deletion is no longer observed. Anything else we need to know?: Worked w/ to figure this out after all pods in a node got evicted without apparent reason. Environment: Kubernetes version (use ): 1.17.3 (but looking at the code seems to affect all of 1.17.x and 1.18.x and master. Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): 5.x Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A cc (owners of this code)
There seems to be at least .
Code change:
"//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/fields:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/labels:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//staging/src/k8s.io/client-go/kubernetes/fake:go_default_library", "//staging/src/k8s.io/client-go/testing:go_default_library",

Related discussion:
text: You can sort of get a feel for what's going on here by looking at these two code snippets: This is what happens in when the node does not have any NoExecute taints: If you have any NoExecute taints on the node processPodOnNode gets called and this routine is really, really eager to evict pods. So : We are currently working around this issue by changing over our NoExecute taints to NoSchedule.
/sig scheduling node
/cc
/remove-sig scheduling scheduler isn't involved in this case.
Which SIG owns the controller-manager or is the node lifecycle manager (and its NoExecuteTaintManager) owned by sig-node alone?
I think node lifecycle is jointly owned by sig-node and sig-cloud-provider
API machinery owns the mechanics of the controller manager (controller loop setup and management), but the individual controllers are SIG-specific
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
Looks like we lost some momentum here and I'd like to avoid this falling into the abyss of bugs that never get fixed. When this bug is triggered the outcome is pretty terrible and once it does happen it is very difficult to dig into and understand what actually happened. Did we ever get this routed to the right owner?
adding sig-node leads for triage/routing. this seems like a clearly reproducible bug with significant correctness issues. /assign
thanks for the detailed report and reproducer. to help accelerate this, do you have a form of your reproducer we could add in the e2e suite (even if its failing initially)?
custom taints are considered disruptive, so it couldn't run in the main suite
It's been a while since I wrote tests for the e2e suite but if you are available over slack in case guidance is needed, I'm willing to put the effort.
Do all suites need to pass for a fix to be merged? I'd assume it is the case, otherwise how would a regression be prevented after the fix lands?
Code change:
"//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/fields:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/labels:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//staging/src/k8s.io/client-go/kubernetes/fake:go_default_library", "//staging/src/k8s.io/client-go/testing:go_default_library",

Related discussion:
text: i was more inquiring if there was a test that could automate the reproduction, so even just a linked commit may be helpful for someone that wants to pick this up. i am happy to help if you want to reach out over slack later this week.
looks like a unit test could reproduce the issue, opened a WIP fix in
our code is not publicly accessible, I'm sorry. PR linked by seems to cover both the fix and the test that proves it.
/remove-lifecycle frozen
frozen keeps the bot from auto-closing
Ah, sorry then.
Code change:
package validation import ( <ins> "runtime" </ins> "strings" "testing"

Related discussion:
text: test withnot FAIL In a macos. do or golang upstrem disscusion. We use time.LoadLocation to validate timezone setting in object spec like cronjob.(It is ok) We also add a test try to validate is not a crroct value. This test is not true sometimes, for example, in default macos this is a true time_zone value.(maybe also true in other case insensitive os, but I have no device to try) At least we should get the test to pass on macos, I hope. <details</details<details</details<details</details<details</details<details</details<details</details
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig test (I guess) 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
/sig testing (I guess)
see
/remove-sig testing /sig apps
I was very surprised to find that this error only occurs on darwin, and does not occur on windows, although windows is also case-sensitive by default. When using , windows finally use (see ), but darwin and linux have more choices (see ) they will first try , using the method, which will call the system's open method to open , because darwin is case-insensitive by default, and this operation will succeed.
/triage accepted