Skip to content
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

Merged
merged 1 commit into from Nov 15, 2021
Merged

Ignore Pods With Deletion Timestamp #639

merged 1 commit into from Nov 15, 2021

Conversation

JaneLiuL
Copy link
Member

@JaneLiuL JaneLiuL commented Oct 1, 2021

Enhance ignore Pods With Deletion Timestamp for all strategies
Issue: #638

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Oct 1, 2021
@k8s-ci-robot
Copy link
Contributor

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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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.

@k8s-ci-robot k8s-ci-robot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Oct 1, 2021
@k8s-ci-robot k8s-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Oct 1, 2021
@JaneLiuL
Copy link
Member Author

JaneLiuL commented Oct 1, 2021

/ok-to-test

@k8s-ci-robot
Copy link
Contributor

@JaneLiuL: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/ok-to-test

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.

Copy link
Contributor

@damemi damemi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/ok-to-test

@k8s-ci-robot k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Oct 1, 2021
pkg/utils/pod.go Show resolved Hide resolved
@JaneLiuL
Copy link
Member Author

JaneLiuL commented Oct 2, 2021

/retest

Copy link
Contributor

@a7i a7i left a 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.

pkg/utils/pod.go Outdated Show resolved Hide resolved
@damemi
Copy link
Contributor

damemi commented Oct 15, 2021

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

@JaneLiuL
Copy link
Member Author

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~

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 18, 2021
@JaneLiuL
Copy link
Member Author

/assign @damemi

Copy link
Contributor

@damemi damemi left a 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?

README.md Outdated Show resolved Hide resolved
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 26, 2021
@k8s-ci-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 26, 2021
@JaneLiuL
Copy link
Member Author

/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) {},
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Member Author

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?

Copy link
Member Author

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?

Copy link
Contributor

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!

pkg/descheduler/strategies/pod_antiaffinity_test.go Outdated Show resolved Hide resolved
expectedEvictedPodCount: 3,
testFunc: func(podList []v1.Pod) {
for _, pod := range podList {
pod.DeletionTimestamp = &metav1.Time{}
Copy link
Contributor

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?

Copy link
Member Author

@JaneLiuL JaneLiuL Nov 2, 2021

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fix done~ Please check :)

Copy link
Contributor

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

Copy link
Member Author

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?

pkg/descheduler/strategies/pod_antiaffinity_test.go Outdated Show resolved Hide resolved
@@ -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) {},
Copy link
Contributor

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})
Copy link
Contributor

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

Copy link
Member Author

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?

@ingvagabund
Copy link
Contributor

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Nov 15, 2021
@k8s-ci-robot k8s-ci-robot merged commit d0f11a4 into kubernetes-sigs:master Nov 15, 2021
briend pushed a commit to briend/descheduler that referenced this pull request Feb 11, 2022
Ignore Pods With Deletion Timestamp
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants