kube-scheduler-simulator
kube-scheduler-simulator copied to clipboard
Support v1beta3 KubeSchedulerConfiguration
What type of PR is this?
/kind feature
What this PR does / why we need it:
Currently the simulator only supports v1beta2 scheduler config. This PR will move it forward to only support the latest v1beta3.
Which issue(s) this PR fixes:
Fixes #46
Special notes for your reviewer:
Issue was not clear if we intend to support both v1beta2 and v1beta3 so this is starting with only v1beta3. If we need both, then we could use this as partial-fix, raise new issue, or just keep working on this PR.
/label tide/merge-method-squash
Hi @markstur. 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.
/assign @sanposhiho
I'm assuming you'd like to review. I feel like the test cases (and my experience) for v1beta3 are kind of lacking. Advice?
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: markstur To complete the pull request process, please ask for approval from sanposhiho after the PR has been reviewed.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve
in a comment
Approvers can cancel approval by writing /approve cancel
in a comment
@markstur Thanks! I'll review it later.
Issue was not clear if we intend to support both v1beta2 and v1beta3 so this is starting with only v1beta3. If we need both, then we could use this as partial-fix, raise new issue, or just keep working on this PR.
I think just supporting latest version (v1beta3) is enough.
/ok-to-test
@markstur
v1beta3 supports multipoint
field and we need to consider that.
https://kubernetes.io/docs/reference/scheduling/config/#multipoint https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/2891-simplified-config
In current simulator, when users requests to change the scheduler configuration,
- excludes non-allowed changes in configuration.
- replaces filter/score default-plugins with plugins for simulator in
ConvertForSimulator
. - replaces filter/score default-plugins config with configs for plugins for simulator in
NewPluginConfig
.
So, in v1beta3, we need to replace filter/score plugins configured by multipoint
with plugins for simulator as well.
I expect this will require a slightly more complex change and will be the most difficult part of v1beta3 support.
@markstur: PR needs rebase.
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.
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,
lifecycle/stale
is applied - After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied - After 30d of inactivity since
lifecycle/rotten
was applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale
- Mark this issue or PR as rotten with
/lifecycle rotten
- Close this issue or PR with
/close
- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
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,
lifecycle/stale
is applied - After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied - After 30d of inactivity since
lifecycle/rotten
was applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale
- Mark this issue or PR as rotten with
/lifecycle rotten
- Close this issue or PR with
/close
- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale