Closed MarcPow closed 1 year ago
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please assign ingvagabund for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.
Hi @MarcPow. 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.
/ok-to-test thanks @MarcPow, I understand wanting to hold off on adding tests but it would be helpful to understand the change if you could add a couple test cases to demonstrate
@MarcPow: The following tests failed, say /retest
to rerun all failed tests or /retest-required
to rerun all mandatory failed tests:
Test name | Commit | Details | Required | Rerun command |
---|---|---|---|---|
pull-descheduler-unit-test-master-master | 7ba113a914dfefa2f76eb08ef90c8638483c1e73 | link | true | /test pull-descheduler-unit-test-master-master |
pull-descheduler-verify-master | 7ba113a914dfefa2f76eb08ef90c8638483c1e73 | link | true | /test pull-descheduler-verify-master |
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.
Thank you @MarcPow for this change, looks very thorough.
However, we are planning on introducing a NodeFitSpec
that will give more flexibility as to what thing to check in order to identify eligible nodes.
Please see this comment on the Issue. What do you think?
/label tide/merge-method-squash
Thank you @MarcPow for this change, looks very thorough.
However, we are planning on introducing a
NodeFitSpec
that will give more flexibility as to what thing to check in order to identify eligible nodes.Please see this comment on the Issue. What do you think?
I think we're all on the same page with respect to the need. The original proposal was a good one, but I think it was made independent of / prior to the changes that happened in the podTopologySpreadConstraints spec that added more controls here. At the point that those behaviors were added, I think the call on the descheduler is simply to behave just as the scheduler itself would when placing the pods in the first place. An independent, separate policy has thus become unnecessary.
Closing this PR, allowing this change to be carried forward by #1208
Proposing a potential fix for #1204.
Looking for feedback before adding unit tests, etc.
The current code assumes that a couple of beta feature flags around are currently enabled by default.