New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ignore Pods With Deletion Timestamp #639
Conversation
Hi @JaneLiuL. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test |
@JaneLiuL: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/ok-to-test
/retest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thoughts on updating README to indicate that going forward Pods that are being deleted are ignored. This is important because Pods that have a long termination grace period will no longer be considered for eviction so it's a change in behavior.
This should definitely be updated in the readme, yeah. We might even want to make this a non-default behavior |
Update done, please check~ |
/assign @damemi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/hold cancel
/approve
one nit in the readme but I think it looks good. @seanmalloy do you want to take a look too?
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: a7i, damemi, JaneLiuL The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
@@ -245,12 +253,34 @@ func TestPodLifeTime(t *testing.T) { | |||
pods: []v1.Pod{*p12, *p13}, | |||
nodes: []*v1.Node{node1}, | |||
expectedEvictedPodCount: 1, | |||
testFunc: func(podList []v1.Pod) {}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no need for testFunc
which sets the DeletionTimestamp
only for pods p12
and p13
. Can you create pods p14
and p15
instead as copies of p12
and p13
and set the DeletionTimestamp
explicitly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @ingvagabund thanks for the reivew~~
I think testFunc
is more easy to extend on the test case. This time we only enhance for DeletionTimestamp, maybe next time we need to do other actions on the Pod. So for me, testFunc is more like a BuildTestNode
or BuildTestPod
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JaneLiuL that's not bad thinking to think ahead, but we don't have any use cases or evidence that we'll need more extensibility at this time. If we do come across that, the test can be refactored then, but for now adding a testFunc is unnecessary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ingvagabund @damemi Thanks for your comment~
Then I will try to remove the testFunc, and create the new testPod with deleteTimestamp, is it better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Already remove testFunc
, may I click Resolve conversation
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this is looking a lot cleaner now, thanks!
expectedEvictedPodCount: 3, | ||
testFunc: func(podList []v1.Pod) { | ||
for _, pod := range podList { | ||
pod.DeletionTimestamp = &metav1.Time{} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This actually modifies the pods permanently. Each test needs a freshly created pod. Instead, can you create new pods (e.g. p5 - p8) which have the DeletionTimestamp
set right away?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @ingvagabund ~ I learned a lot~~ . I don't know that testcase need a freashly created pod before. So I would create a new pod for this test case, and because it already have (p5-p8) so I would create a (p9-p10) is it ok for you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix done~ Please check :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JaneLiuL if you are creating p9 and p10 now specifically for this test, do you still need testFunc
at all? you can just specify those pods with an empty timestamp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Already remove testFunc
, may I click Resolve conversation
?
@@ -245,12 +253,34 @@ func TestPodLifeTime(t *testing.T) { | |||
pods: []v1.Pod{*p12, *p13}, | |||
nodes: []*v1.Node{node1}, | |||
expectedEvictedPodCount: 1, | |||
testFunc: func(podList []v1.Pod) {}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JaneLiuL that's not bad thinking to think ahead, but we don't have any use cases or evidence that we'll need more extensibility at this time. If we do come across that, the test can be refactored then, but for now adding a testFunc is unnecessary
}, | ||
} | ||
|
||
for _, tc := range testCases { | ||
fakeClient := &fake.Clientset{} | ||
|
||
tc.testFunc([]v1.Pod{*p12, *p13}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is again calling testFunc for just p12 and p13 on every test, even though the pods are only used in 1 test. this shouldn't be necessary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Already remove testFunc
, may I click Resolve conversation
?
/lgtm |
Ignore Pods With Deletion Timestamp
Enhance ignore Pods With Deletion Timestamp for all strategies
Issue: #638