What is the problem you're trying to solve
When DRA support was introduced in Volcano, the reused kube-scheduler DRA plugin only needed to be adapted for extension points such as PreFilter, Filter, Reserve, and PreBind.
In Kubernetes v1.34, the DRA plugin added scoring support through Score and NormalizeScore. These extension points are not wired into Volcano yet, so DRA scoring behavior may be different from kube-scheduler after upgrading the Kubernetes dependency.
There is also a broader maintenance problem. Some Volcano plugins reuse kube-scheduler in-tree plugins, but Volcano does not always support every kube-scheduler extension point directly. For example, extension points like PreEnqueue or Sign may not map cleanly to Volcano's scheduling flow. When a reused kube-scheduler plugin adds a new extension point in a future Kubernetes release, it is easy to miss that during dependency upgrades.
Describe the solution you'd like
First, support the DRA Score and NormalizeScore path in Volcano's predicates plugin. DRA should be registered as a score plugin when enabled, and the score helper should call the plugin's own ScoreExtensions() so NormalizeScore can run when provided.
Second, add an automated guardrail for kube-scheduler plugin extension point changes. The idea is to maintain an explicit decision list for each kube-scheduler plugin reused by Volcano:
- extension points adapted by Volcano
- extension points intentionally ignored because they do not fit Volcano's scheduling flow
A test or verify script can instantiate or inspect the reused kube-scheduler plugin and detect which kube-scheduler framework interfaces it currently implements. If the plugin implements an extension point that is neither adapted nor intentionally ignored, the check should fail and ask maintainers to make an explicit decision.
For example, after a Kubernetes dependency upgrade, if DRA starts implementing a new extension point, CI should report something like:
DynamicResources implements Score, but Volcano has not marked it as adapted or intentionally ignored.
Please decide whether this extension point should be supported in Volcano.
This would help catch behavior changes during Kubernetes version upgrades without forcing Volcano to implement every kube-scheduler extension point.
Additional context
This is mainly about plugins imported from kube-scheduler, such as DynamicResources/DRA and VolumeBinding.
For extension points that Volcano does not intend to support, the goal is not to wire them in automatically. The goal is to make the decision explicit and visible during dependency upgrades.
What is the problem you're trying to solve
When DRA support was introduced in Volcano, the reused kube-scheduler DRA plugin only needed to be adapted for extension points such as
PreFilter,Filter,Reserve, andPreBind.In Kubernetes v1.34, the DRA plugin added scoring support through
ScoreandNormalizeScore. These extension points are not wired into Volcano yet, so DRA scoring behavior may be different from kube-scheduler after upgrading the Kubernetes dependency.There is also a broader maintenance problem. Some Volcano plugins reuse kube-scheduler in-tree plugins, but Volcano does not always support every kube-scheduler extension point directly. For example, extension points like
PreEnqueueorSignmay not map cleanly to Volcano's scheduling flow. When a reused kube-scheduler plugin adds a new extension point in a future Kubernetes release, it is easy to miss that during dependency upgrades.Describe the solution you'd like
First, support the DRA
ScoreandNormalizeScorepath in Volcano's predicates plugin. DRA should be registered as a score plugin when enabled, and the score helper should call the plugin's ownScoreExtensions()soNormalizeScorecan run when provided.Second, add an automated guardrail for kube-scheduler plugin extension point changes. The idea is to maintain an explicit decision list for each kube-scheduler plugin reused by Volcano:
A test or verify script can instantiate or inspect the reused kube-scheduler plugin and detect which kube-scheduler framework interfaces it currently implements. If the plugin implements an extension point that is neither adapted nor intentionally ignored, the check should fail and ask maintainers to make an explicit decision.
For example, after a Kubernetes dependency upgrade, if DRA starts implementing a new extension point, CI should report something like:
This would help catch behavior changes during Kubernetes version upgrades without forcing Volcano to implement every kube-scheduler extension point.
Additional context
This is mainly about plugins imported from kube-scheduler, such as DynamicResources/DRA and VolumeBinding.
For extension points that Volcano does not intend to support, the goal is not to wire them in automatically. The goal is to make the decision explicit and visible during dependency upgrades.