From 66b1bc9951a11ae479d74fd1dd12a5d6c000132e Mon Sep 17 00:00:00 2001
From: Morten Torkildsen <mortent@google.com>
Date: Tue, 7 Oct 2025 20:44:14 +0000
Subject: [PATCH 1/4] [KEP-4816] Simple scoring for DRA Prioritized List
 feature

---
 .../4816-dra-prioritized-list/README.md       | 22 +++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/keps/sig-scheduling/4816-dra-prioritized-list/README.md b/keps/sig-scheduling/4816-dra-prioritized-list/README.md
index 3cbe5895213..26268997315 100644
--- a/keps/sig-scheduling/4816-dra-prioritized-list/README.md
+++ b/keps/sig-scheduling/4816-dra-prioritized-list/README.md
@@ -91,6 +91,7 @@ tags, and then generate with `hack/update-toc.sh`.
   - [Risks and Mitigations](#risks-and-mitigations)
 - [Design Details](#design-details)
   - [Scheduler Implementation](#scheduler-implementation)
+    - [Scoring](#scoring)
   - [Test Plan](#test-plan)
       - [Prerequisite testing updates](#prerequisite-testing-updates)
       - [Unit tests](#unit-tests)
@@ -899,6 +900,27 @@ would need a higher score, which currently is planned for beta of this feature.
 For alpha, the scheduler may still pick a node with a less preferred device, if
 there are nodes with each type of device available.
 
+#### Scoring
+
+Full support for scoring in DRA is not in scope for this feature, but we will
+implement limited scoring to make sure that nodes which can satisfy claims with
+higher ranked subrequests are preferred over others.
+
+We will implement this by letting the dynamicresources scheduler plugin implement
+the `Score` interface. 
+
+The allocation result for each node will be given a score based on the ranking of
+the chosen subrequests across all requests using the `FirstAvailable` field across
+all claims referenced by the Pod. Since the number of subrequests for each request
+is capped at 8, we will compute a score between 1 and 8 for each request, with 8
+being the best (i.e. the first option was chosen) and 1 if the 8th subrequest was
+chosen. We save the score of 0 in case we want to implement optional requests. Since
+the score for every node is computed based on the same claims, we end up with a
+ranking of the results from all nodes.
+
+We don't see a need to normalize the scores for now, but this might be needed when
+we implement more complicated scoring in the future.
+
 ### Test Plan
 
 <!--

From 74588a8af73909cc72ce4b156706f2c9ce40ed8c Mon Sep 17 00:00:00 2001
From: Morten Torkildsen <mortent@google.com>
Date: Wed, 8 Oct 2025 21:54:16 +0000
Subject: [PATCH 2/4] Update latest milestone

---
 keps/sig-scheduling/4816-dra-prioritized-list/kep.yaml | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/keps/sig-scheduling/4816-dra-prioritized-list/kep.yaml b/keps/sig-scheduling/4816-dra-prioritized-list/kep.yaml
index bc84e4c9540..a312c317bfa 100644
--- a/keps/sig-scheduling/4816-dra-prioritized-list/kep.yaml
+++ b/keps/sig-scheduling/4816-dra-prioritized-list/kep.yaml
@@ -28,13 +28,12 @@ stage: beta
 # The most recent milestone for which work toward delivery of this KEP has been
 # done. This can be the current (upcoming) milestone, if it is being actively
 # worked on.
-latest-milestone: "v1.34"
+latest-milestone: "v1.35"
 
 # The milestone at which this feature was, or is targeted to be, at each stage.
 milestone:
   alpha: "v1.33"
   beta: "v1.34"
-  stable: "v1.35"
 
 # The following PRR answers are required at alpha release
 # List the feature gate name and the components for which it must be enabled

From 6ae8e045b129e249644bfd57118e5d9df965d48e Mon Sep 17 00:00:00 2001
From: Morten Torkildsen <mortent@google.com>
Date: Thu, 9 Oct 2025 20:24:40 +0000
Subject: [PATCH 3/4] Addressed comments

---
 .../4816-dra-prioritized-list/README.md       | 26 +++++++++++--------
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/keps/sig-scheduling/4816-dra-prioritized-list/README.md b/keps/sig-scheduling/4816-dra-prioritized-list/README.md
index 26268997315..debb113a5e3 100644
--- a/keps/sig-scheduling/4816-dra-prioritized-list/README.md
+++ b/keps/sig-scheduling/4816-dra-prioritized-list/README.md
@@ -291,15 +291,13 @@ type `DeviceSubRequest`. The `DeviceSubRequest` type is similar to
 available when providing multiple alternatives. The list provided in the
 `FirstAvailable` field is considered a priority order, such that the
 scheduler will use the first entry in the list that satisfies the
-requirements. 
+requirements.
 
-DRA does not yet implement scoring, which means that
-the selected devices might not be optimal. For example, if a prioritized
-list is provided in a request, DRA might choose entry number two on node A,
-even though entry number one would meet the requirements on node B. This is
-consistent with current behavior in DRA where the first match will be chosen.
-Scoring is something that will be implemented later, with early discussions
-in https://github.com/kubernetes/enhancements/issues/4970
+DRA does not yet implement full scoring (tracked in
+https://github.com/kubernetes/enhancements/issues/4970), but we will implement
+a limited form of scoring for this feature. This is to make sure nodes which
+can satisfy a claim with higher ranked subrequests are preferred over others. The
+details are described in the [Scoring](#scoring) section.
 
 ### User Stories
 
@@ -907,7 +905,7 @@ implement limited scoring to make sure that nodes which can satisfy claims with
 higher ranked subrequests are preferred over others.
 
 We will implement this by letting the dynamicresources scheduler plugin implement
-the `Score` interface. 
+the `Score` and `NormalizeScore` interfaces. 
 
 The allocation result for each node will be given a score based on the ranking of
 the chosen subrequests across all requests using the `FirstAvailable` field across
@@ -918,8 +916,14 @@ chosen. We save the score of 0 in case we want to implement optional requests. S
 the score for every node is computed based on the same claims, we end up with a
 ranking of the results from all nodes.
 
-We don't see a need to normalize the scores for now, but this might be needed when
-we implement more complicated scoring in the future.
+We will implement the `NormalizeScore` interface to normalize the results. We aim
+to do this in a way such that the worst selection possible (where the last subrequest
+is chosen for all requests specifying the `FirstAvailable` field) is given a score of
+0, and the best selection possible (where the first subrequest is chosen for all requests
+specifying the `FirstAvailable` field) is given a score of 100. This makes sure that the
+score accurately reflects "how much better" one alternative is compared to another.
+
+We will give the plugin a weight of 2 since it reflects scoring based on user preference.
 
 ### Test Plan
 

From 59fb547522744354076bb6d6445e7782d4602694 Mon Sep 17 00:00:00 2001
From: Morten Torkildsen <mortent@google.com>
Date: Fri, 10 Oct 2025 16:51:45 +0000
Subject: [PATCH 4/4] Addressed comments

---
 .../4816-dra-prioritized-list/README.md          | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/keps/sig-scheduling/4816-dra-prioritized-list/README.md b/keps/sig-scheduling/4816-dra-prioritized-list/README.md
index debb113a5e3..93db94618ab 100644
--- a/keps/sig-scheduling/4816-dra-prioritized-list/README.md
+++ b/keps/sig-scheduling/4816-dra-prioritized-list/README.md
@@ -618,13 +618,11 @@ type DeviceRequest struct {
     //
     // This field may only be set in the entries of DeviceClaim.Requests.
     //
-    // DRA does not yet implement scoring, so the scheduler will
-    // select the first set of devices that satisfies all the
-    // requests in the claim. And if the requirements can
-    // be satisfied on more than one node, other scheduling features
-    // will determine which node is chosen. This means that the set of
-    // devices allocated to a claim might not be the optimal set
-    // available to the cluster. Scoring will be implemented later.
+    // DRA does not yet implement full scoring, but it implements limited
+    // scoring so that nodes that can satisfy high ranked subrequests are
+    // preferred over others. The node ultimately chosen also depends on
+    // other scheduling features, so it is not guaranteed that the node
+    // preferred by DRA is chosen.
     //
     // +optional
     // +oneOf=deviceRequestType
@@ -912,7 +910,9 @@ the chosen subrequests across all requests using the `FirstAvailable` field acro
 all claims referenced by the Pod. Since the number of subrequests for each request
 is capped at 8, we will compute a score between 1 and 8 for each request, with 8
 being the best (i.e. the first option was chosen) and 1 if the 8th subrequest was
-chosen. We save the score of 0 in case we want to implement optional requests. Since
+chosen. If there are more than one request using the `FirstAvailable` field the score from
+all of them will be added up to get the score for the pod on the node.
+Since
 the score for every node is computed based on the same claims, we end up with a
 ranking of the results from all nodes.