KEP-5491: DRA: List Types for Attributes by everpeace · Pull Request #5698 · kubernetes/enhancements

everpeace · 2025-11-19T15:30:04Z

One-line PR description: Device attributes in a ResourceSlice may now be lists, rather than just scalars. And matchAttribute/distinctAttribute constaint are extended as "non-empty intersection" semantics (scalar can be implicitly treated as single value list).

Issue link: DRA: List Types for Attributes #5491

Other comments: This is an initial draft.

/wg device-management
/sig scheduling

k8s-ci-robot · 2025-11-19T15:30:07Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

johnbelamaric · 2026-02-10T22:27:04Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+- Initial supported semantics are
+  - `NonEmptyIntersection` and `Identical` for `matchAttribute`
+  - `EmptyIntersection`, `PairwiseDisjoint`, and `AllDistinct` for `distinctAttribute`
+- Maintain backward compatibility and inter-operability for scalar-only attributes.


We also need to figure out what to do with CEL expressions

Agreed.

Figuring out how existing cel expressions comparing attributes to single-value scalars work in the presence of list attributes is important. A set of strawman examples using a hypothetical includes helper:

.attributes["foo"] is 1 `.attributes["foo"] == 1` cel -> true `.attributes["foo"].includes(1)` cel -> true .attributes["foo"] is [1] `.attributes["foo"] == 1` cel -> ?, maybe true? can maybe do with an overload if we want to `.attributes["foo"].includes(1)` cel -> true .attributes["foo"] is [1,2] `.attributes["foo"] == 1` cel -> ?, probably false `.attributes["foo"].includes(1)` cel -> true

Wow, thanks for the great feedback! The compatibility I originally referred to only supposed the ResourceClaim's constraint objects.

Figuring out how existing cel expressions comparing attributes to single-value scalars work in the presence of list attributes is important.

But, I feel it's very difficult. If the attribute type is changed, I think it will be difficult to keep existing CEL expressions working without any modifications. This happens with any type changes, not only with scalar to list. It is because CEL is a strongly typed language, the types simply won’t match, i.e. it won’t compile.

Thus, even if we provide some helper functions/macros, I think we basically have to ask users to update thier CELs....

What do you think??

note: include could be written with standard exists macro, right?

.attributes["foo"].includes(1) <==> .attributes["foo"].exists(x, x == 1)

I fully agree include is much easier to read though.

So you can't override == in CEL? You can't do type coercion in operators?

If that's the case and so how it behaves today for other types, probably we should just fail and not try to solve this for users. It's unfortunate to need users to update CEL based on what version of the driver is running, though.

If I'm reading this right we want a more convenient equivalent of type(attributes["foo"]) == list ? 1 in attributes["foo"] : attributes["foo"] == 1 ?

While it MIGHT be possible to define a CEL custom type that allows for a list type where attributes["foo"] == 1 is equivalent to attributes["foo"] == [1], it wouldn't be idiomatic. I don't recommend going that way. It would diverge from normal CEL type system expectations and feels confusing to anyone that already has an understanding of how the CEL type system is suppose to work.

The options I can think of are:

Add a function like @liggitt suggested above. CEL supports function overloading so it's unsurprising in CEL to have a function operate differently depending on receiver and argument types.

Overload the in operate to allow for 1 in attributes["foo"].

I prefer adding a function. I consider overloading in less bad than overloading == but it's still surprising.

Thanks, Joe. @everpeace let's add a helper function that can do the type-agnostic comparison in CEL.

@dom4ha once that's in, I think this is ready to go!

Oh, thanks for the great discussion! OK. I'll add type-agnostic helper function (say .include). I'll update the KEP.

added: fixed in 2e25605

dom4ha · 2026-02-11T02:15:29Z

Such constraints will greatly complicate scheduling. Do we have any idea how we could approach it systematically to avoid checking all permutations?

johnbelamaric · 2026-02-11T05:20:39Z

The simple version just changes the exist "equal" and "not equal" functions to do type coercions. So it has no impact on permutation evaluation.

Co-authored-by: John Belamaric <[email protected]>

…matchAttribute semantics)

…monotinicity" to goal

…original one(introducing *Semantics fields) to Alternative seceion.

everpeace

@johnbelamaric @liggitt Thank you very much for the review!! I largely simplified the proposal so that it proposed just adding list type and no API changes on constraints side but just extending the semantics (No complex *Semantics fields).

Please take a look.

For the backward compatibility on existing CELs(in device selectors) issue, I also commented(I think it's hard...). Let's keep discussing.

keps/sig-scheduling/5491-dra-list-types-for-attributes/kep.yaml

everpeace · 2026-02-11T12:11:07Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+A good summary is probably at least a paragraph in length.
+-->
+
+The Device Resource Assignment (DRA) API currently allows scalar attribute values to describe device characteristics. However, many real-world device topologies require representing sets of relationships (e.g., multiple PCIe roots, NUMA nodes). This KEP introduces support for list-typed attributes in `ResourceSlice` and extends `ResourceClaim`'s `constraints` with a new declarative field, `matchSemantics`/`distinctSemantics`, that can configure _how_ attribute values should be evaluated.


OK. Let's remove *Semantics fields

everpeace · 2026-02-11T12:12:41Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+
+- Support typed-list in device attribute values.
+- Define an extensible API in `ResourceClaim`'s `constraints` field which enables flexible matching semantics against single device attribute value.
+- Initial supported semantics are


Right, we haven't had usecases for them. I'll remove this bullet item from the goal.

everpeace · 2026-02-11T13:10:12Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+- Initial supported semantics are
+  - `NonEmptyIntersection` and `Identical` for `matchAttribute`
+  - `EmptyIntersection`, `PairwiseDisjoint`, and `AllDistinct` for `distinctAttribute`
+- Maintain backward compatibility and inter-operability for scalar-only attributes.


Wow, thanks for the great feedback! The compatibility I originally referred to only supposed the ResourceClaim's constraint objects.

Figuring out how existing cel expressions comparing attributes to single-value scalars work in the presence of list attributes is important.

But, I feel it's very difficult. If the attribute type is changed, I think it will be difficult to keep existing CEL expressions working without any modifications. This happens with any type changes, not only with scalar to list. It is because CEL is a strongly typed language, the types simply won’t match, i.e. it won’t compile.

Thus, even if we provide some helper functions/macros, I think we basically have to ask users to update thier CELs....

What do you think??

note: include could be written with standard exists macro, right?

.attributes["foo"].includes(1) <==> .attributes["foo"].exists(x, x == 1)

I fully agree include is much easier to read though.

everpeace · 2026-02-11T13:11:24Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+- Redesigning the entire DRA matching model.
+  - Currently `Allocator`'s algorithm assumes [_monotonic_ constraints](https://github.com/kubernetes/kubernetes/blob/v1.34.2/staging/src/k8s.io/dynamic-resource-allocation/structured/internal/experimental/allocator_experimental.go#L274-L276) only. Monotonic means that once a constraint returns false, adding more devices will never cause it to return true. This allows to bound the computational complexity for searching device combinations which satisfies the specified constraints. This KEP does NOT intend to change this design. Thus, this KEP focuses to propose monotonic constraints only.


OK. I will move this in goal section.

everpeace · 2026-02-11T14:18:09Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+A good summary is probably at least a paragraph in length.
+-->
+
+The Device Resource Assignment (DRA) API currently allows scalar attribute values to describe device characteristics. However, many real-world device topologies require representing sets of relationships (e.g., multiple PCIe roots, NUMA nodes). This KEP introduces support for list-typed attributes in `ResourceSlice` and extends `ResourceClaim`'s `constraints` with a new declarative field, `matchSemantics`/`distinctSemantics`, that can configure _how_ attribute values should be evaluated.


fixed in 4f8c6c1

everpeace · 2026-02-11T14:18:41Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+
+- Support typed-list in device attribute values.
+- Define an extensible API in `ResourceClaim`'s `constraints` field which enables flexible matching semantics against single device attribute value.
+- Initial supported semantics are


fixed in 75c65b2

everpeace · 2026-02-11T14:19:08Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+- Redesigning the entire DRA matching model.
+  - Currently `Allocator`'s algorithm assumes [_monotonic_ constraints](https://github.com/kubernetes/kubernetes/blob/v1.34.2/staging/src/k8s.io/dynamic-resource-allocation/structured/internal/experimental/allocator_experimental.go#L274-L276) only. Monotonic means that once a constraint returns false, adding more devices will never cause it to return true. This allows to bound the computational complexity for searching device combinations which satisfies the specified constraints. This KEP does NOT intend to change this design. Thus, this KEP focuses to propose monotonic constraints only.


fixed in 2111773

everpeace · 2026-02-11T14:19:25Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+  pool:
+    name: "cpu"
+    resourceSliceCount: 1
+  allNodes: node-1


fixed in fc7807b

everpeace · 2026-02-11T14:20:07Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+
+- [x] Feature gate (also fill in values in `kep.yaml`)
+  - Feature gate name: `DRAListTypeAttributes`
+  - Components depending on the feature gate: kube-apiserver, kube-**scheduler**


fixed in e3154f2

johnbelamaric · 2026-02-11T17:55:50Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+NOTE: Also set `disable-supported` to `true` or `false` in `kep.yaml`.
+-->
+
+Yes. When disabled, you can not create `ResourceClaim` with `matchSemantics`/`distinctSemantics` nor `DeviceAttribute` with `list`-type values. And, existing `list`-type attribute values are just ignored. But, if specified attribute in `matchAttribute`/`distinctAttribute` is `list` type, allocation will be failed.


Can you update this based on the simplified design?

Thanks for the catch! I'll update.

added: fixed in 3ca5c9e

johnbelamaric · 2026-02-11T17:57:00Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+
+### Implementation (for evaluating constraints)
+
+Since _non-empty intersection_ constraint is _monotonic_, we would not need updating [`Allocator.Allocate()` algorithm](https://github.com/kubernetes/kubernetes/blob/v1.34.2/staging/src/k8s.io/dynamic-resource-allocation/structured/internal/experimental/allocator_experimental.go#L135) and can keep using [`constraint` interface](https://github.com/kubernetes/kubernetes/blob/v1.34.2/staging/src/k8s.io/dynamic-resource-allocation/structured/internal/experimental/allocator_experimental.go#L703-L712). We will just extend the current [`matchAttributeConstraint`](https://github.com/kubernetes/kubernetes/blob/v1.34.2/staging/src/k8s.io/dynamic-resource-allocation/structured/internal/experimental/allocator_experimental.go#L721C6-L728) and [`distinctAttributeConstraint`](https://github.com/kubernetes/kubernetes/blob/v1.34.2/staging/src/k8s.io/dynamic-resource-allocation/structured/internal/experimental/constraint.go#L34-L41) instances. Or, we could introduce `constraint` instances for proposed modes (e.g., `nonEmptyIntersectionMatchAttributeConstraint`, etc.).


Update this for the simplified design.

Actually, I think this is already updated in e470001e0872739f4042aa347b5d07ca1ddfade6. We need to update allocator implementation so that it can handle list type.

johnbelamaric · 2026-02-11T17:58:50Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+#### Story 2
+
+T.B.D.


I am not aware of use cases for distinct with lists, but because it's a new type, any existing operations need to be updated to handle that type. This is a way to do it that maintains the complimentary nature of the two types of constraints.

dom4ha

Simplified enhancement looks good and does not add much complexity. If you come up with a conclusion regarding CEL, I will have time tomorrow morning to approve this KEP.

dom4ha · 2026-02-11T19:52:58Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+[experience reports]: https://github.com/golang/go/wiki/ExperienceReports
+-->
+
+The `ResourceSlice` API allows users to attach scalar attributes to devices. These can be used to allocate devices that share common topology within the node. For certain types of topological relationships, scalar values are insufficient. For example, a CPU may have adjacency to multiple PCIe roots. This enhancement proposes allowing attributes to be lists. The semantics of the `MatchAttribute` and `DistinctAttribute` constraints must adapt to the possibility of lists. For example, rather than defining an attribute "match" as equality, it would be defined as a non-empty intersection, treating scalars as single-element lists. Conversely, "distinct" attributes for lists would be defined as an empty intersection.


For example, a CPU may have adjacency to multiple PCIe roots

Is adjacency to PCIe roots is the same as running on a PCIe root? Can we have a device which is running on a given root and is adjacent to another two at the same time.

Can all those three roots be advertised as resource.kubernetes.io/pcieRoot or need to have separate labels like resource.kubernetes.io/adjacentPcieRoot for which we cannot construct a common matchAttribute constraint?

One attribute is sufficient for all the known use cases, there are not two different types of relationships, it's just not a singular relationship for CPUs.

dom4ha · 2026-02-11T19:59:25Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

The simple version just changes the exist "equal" and "not equal" functions to do type coercions. So it has no impact on permutation evaluation.

I see, so we don't make it any worse and keep using monotonic search algorithm and consider all values from the list rather than one.

However, matchAttribute functionality itself makes the search computationally expensive and it needs to be performed per each node. Do we know how it's doing in practices? I could easily imagine that it would generate many possible options to scan (even without CEL constraints #5254).

Another question is how users are handling these complex constraints and debug why they workload haven't scheduled. We faced very similar concern regarding a KEP proposing adding CEL expressions to tolerations #5822 and for now we've put it on hold. The questions are similar in both cases.

I don't have any real world data on that; in simulations it's not too bad. The current naive algorithm is more-or-less a brute force search. But with the well-defined semantics of match it's possible to optimize the algorithm to reduce the search space quickly. That sort of thing can be achieved, for example, with a simple b-tree.

In practice, we expect these lists to be short, as they correspond for example roughly with number of PCIe switches per CPU. @everpeace is that accurate?

So, doing non-empty intersection is a more expensive operation, for sure. But I doubt it is material (we should measure it in scheduler_perf tests)

However, matchAttribute functionality itself makes the search computationally expensive and it needs to be performed per each node. Do we know how it's doing in practices? I could easily imagine that it would generate many possible options to scan (even without CEL constraints #5254).

It's correct. matchAttribute/distinctAttribute could be basically large complexity. In DRA, Allocator is responsible for searching device comibination which satisfies the given constraint.
But, the Allocator implementation does NOT try all the combination in practice. They have an assumption that the given constraint is monotonic. Monotonic means that once a constraint returns false, adding more devices will never cause it to return true. This allows to bound the computational complexity for searching device combinations in practice.

Another question is how users are handling these complex constraints and debug why they workload haven't scheduled. We faced very similar concern regarding a KEP proposing adding CEL expressions to tolerations #5822 and for now we've put it on hold. The questions are similar in both cases.

Yes. I also recognize this issue. However, I think this issue should be resolved in an separate KEP. I'd like to let this KEP focus to add list type attribute and extending the semantics of matchAttribute/distinctAttribute. WDYT?

In practice, we expect these lists to be short, as they correspond for example roughly with number of PCIe switches per CPU. @everpeace is that accurate?

Although I'm not a specialist of hardware, as far as I know, Yes. Typical large GPU servers may have 2 to 4 PCIe root per socket. And this proposal limits the length of the list attribute with +k8s:maxItems=64

…ection

everpeace

@johnbelamaric @jpbetz @dom4ha Thanks for your review and discussion! I added some commits to address your comments! PTAL 🙇

@dom4ha wrote:

If you come up with a conclusion regarding CEL, I will have time tomorrow morning to approve this KEP.

I think this is concluded in this thread that we will add some helper function, say include, that can work both for scalar and list. The KEP is also updated in 2e25605 for this.

everpeace · 2026-02-12T00:59:33Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

However, matchAttribute functionality itself makes the search computationally expensive and it needs to be performed per each node. Do we know how it's doing in practices? I could easily imagine that it would generate many possible options to scan (even without CEL constraints #5254).

It's correct. matchAttribute/distinctAttribute could be basically large complexity. In DRA, Allocator is responsible for searching device comibination which satisfies the given constraint.
But, the Allocator implementation does NOT try all the combination in practice. They have an assumption that the given constraint is monotonic. Monotonic means that once a constraint returns false, adding more devices will never cause it to return true. This allows to bound the computational complexity for searching device combinations in practice.

Another question is how users are handling these complex constraints and debug why they workload haven't scheduled. We faced very similar concern regarding a KEP proposing adding CEL expressions to tolerations #5822 and for now we've put it on hold. The questions are similar in both cases.

Yes. I also recognize this issue. However, I think this issue should be resolved in an separate KEP. I'd like to let this KEP focus to add list type attribute and extending the semantics of matchAttribute/distinctAttribute. WDYT?

In practice, we expect these lists to be short, as they correspond for example roughly with number of PCIe switches per CPU. @everpeace is that accurate?

Although I'm not a specialist of hardware, as far as I know, Yes. Typical large GPU servers may have 2 to 4 PCIe root per socket. And this proposal limits the length of the list attribute with +k8s:maxItems=64

everpeace · 2026-02-12T01:03:16Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+
+### Implementation (for evaluating constraints)
+
+Since _non-empty intersection_ constraint is _monotonic_, we would not need updating [`Allocator.Allocate()` algorithm](https://github.com/kubernetes/kubernetes/blob/v1.34.2/staging/src/k8s.io/dynamic-resource-allocation/structured/internal/experimental/allocator_experimental.go#L135) and can keep using [`constraint` interface](https://github.com/kubernetes/kubernetes/blob/v1.34.2/staging/src/k8s.io/dynamic-resource-allocation/structured/internal/experimental/allocator_experimental.go#L703-L712). We will just extend the current [`matchAttributeConstraint`](https://github.com/kubernetes/kubernetes/blob/v1.34.2/staging/src/k8s.io/dynamic-resource-allocation/structured/internal/experimental/allocator_experimental.go#L721C6-L728) and [`distinctAttributeConstraint`](https://github.com/kubernetes/kubernetes/blob/v1.34.2/staging/src/k8s.io/dynamic-resource-allocation/structured/internal/experimental/constraint.go#L34-L41) instances. Or, we could introduce `constraint` instances for proposed modes (e.g., `nonEmptyIntersectionMatchAttributeConstraint`, etc.).


Actually, I think this is already updated in e470001e0872739f4042aa347b5d07ca1ddfade6. We need to update allocator implementation so that it can handle list type.

everpeace · 2026-02-12T01:03:59Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+NOTE: Also set `disable-supported` to `true` or `false` in `kep.yaml`.
+-->
+
+Yes. When disabled, you can not create `ResourceClaim` with `matchSemantics`/`distinctSemantics` nor `DeviceAttribute` with `list`-type values. And, existing `list`-type attribute values are just ignored. But, if specified attribute in `matchAttribute`/`distinctAttribute` is `list` type, allocation will be failed.


Thanks for the catch! I'll update.

added: fixed in 3ca5c9e

everpeace · 2026-02-12T01:09:37Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+-->
+Yes and no. It does add new fields, which increase the worst case size of `ResourceSlice` and `ResourceClaim` object. However, the increase size is bounded for most cases:
+- `ResourceClaim`: linear to the number of constraints specified in the resource.
+- `ResourceSlice`: linear to the number of devices defined in the resource. And, the number of list items is also bounded.


OK! Thanks for the info!! I'll keep it in mind. Would you mind sharing some pointer for this validation (varing max/min number of device)??

everpeace · 2026-02-12T02:09:26Z

keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

+- Initial supported semantics are
+  - `NonEmptyIntersection` and `Identical` for `matchAttribute`
+  - `EmptyIntersection`, `PairwiseDisjoint`, and `AllDistinct` for `distinctAttribute`
+- Maintain backward compatibility and inter-operability for scalar-only attributes.


Oh, thanks for the great discussion! OK. I'll add type-agnostic helper function (say .include). I'll update the KEP.

added: fixed in 2e25605

johnbelamaric · 2026-02-12T06:08:40Z

/hold for sig scheduling approval
/approve for PRR

@dom4ha if it looks good to you, please approve and unhold before the deadline.

dom4ha · 2026-02-12T09:02:28Z

/approve
/hold cancel

k8s-ci-robot · 2026-02-12T09:02:39Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dom4ha, everpeace, johnbelamaric

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~keps/prod-readiness/OWNERS~~ [johnbelamaric]
~~keps/sig-scheduling/OWNERS~~ [dom4ha,johnbelamaric]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

everpeace · 2026-02-12T10:43:58Z

@johnbelamaric @dom4ha Thank you very much for your approval!!! I think we need an extra lgtm for merging. Would you mind posting lgtm??

macsko · 2026-02-12T11:28:59Z

/lgtm

k8s-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Nov 19, 2025

k8s-ci-robot requested review from dom4ha and macsko November 19, 2025 15:30

k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory sig/scheduling Categorizes an issue or PR as relevant to SIG Scheduling. labels Nov 19, 2025

github-project-automation bot added this to SIG Scheduling Nov 19, 2025

k8s-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Nov 19, 2025

everpeace force-pushed the KEP-5491-alpha branch 16 times, most recently from 6740a4d to ff35ed6 Compare November 20, 2025 02:02

KEP-5491: Add initial draft for DRA List Types for Attributes

e418c60

everpeace force-pushed the KEP-5491-alpha branch from ff35ed6 to e418c60 Compare November 20, 2025 02:08

everpeace marked this pull request as ready for review November 20, 2025 02:13

k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Nov 20, 2025

KEP-5491: Add PRR request file

8d0f430

johnbelamaric reviewed Feb 10, 2026

View reviewed changes

everpeace and others added 8 commits February 11, 2026 21:00

Update keps/sig-scheduling/5491-dra-list-types-for-attributes/README.md

00cc81b

Co-authored-by: John Belamaric <[email protected]>

update approver

521e0d9

update Summary section (leave out *Semantics field and just redefine …

4f8c6c1

…matchAttribute semantics)

Remove semantics option from Goal section

75c65b2

Remove "adding non-monotonic constraint" from non-goal and add "keep …

2111773

…monotinicity" to goal

fix typo: remove emphasis of kube-scheduler

e3154f2

s/allNodes/nodeName/g

fc7807b

Rewirte Proposal/Alternative section. Simplfy the propocal and added …

e470001

…original one(introducing *Semantics fields) to Alternative seceion.

everpeace commented Feb 11, 2026

View reviewed changes

johnbelamaric reviewed Feb 11, 2026

View reviewed changes

dom4ha reviewed Feb 11, 2026

View reviewed changes

everpeace added 2 commits February 12, 2026 10:05

Remove '*Semantics' sentence from "Feature Enablement and Rollback" s…

3ca5c9e

…ection

Add .include helper function in CEL

2e25605

everpeace commented Feb 12, 2026

View reviewed changes

k8s-ci-robot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Feb 12, 2026

k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 12, 2026

k8s-ci-robot assigned macsko Feb 12, 2026

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 12, 2026

k8s-ci-robot merged commit 1851152 into kubernetes:master Feb 12, 2026
4 checks passed

github-project-automation bot moved this from Needs Review to Done in SIG Scheduling Feb 12, 2026

k8s-ci-robot added this to the v1.36 milestone Feb 12, 2026

		- Redesigning the entire DRA matching model.
		- Currently `Allocator`'s algorithm assumes [_monotonic_ constraints](https://github.com/kubernetes/kubernetes/blob/v1.34.2/staging/src/k8s.io/dynamic-resource-allocation/structured/internal/experimental/allocator_experimental.go#L274-L276) only. Monotonic means that once a constraint returns false, adding more devices will never cause it to return true. This allows to bound the computational complexity for searching device combinations which satisfies the specified constraints. This KEP does NOT intend to change this design. Thus, this KEP focuses to propose monotonic constraints only.


		### Implementation (for evaluating constraints)

		Since _non-empty intersection_ constraint is _monotonic_, we would not need updating [`Allocator.Allocate()` algorithm](https://github.com/kubernetes/kubernetes/blob/v1.34.2/staging/src/k8s.io/dynamic-resource-allocation/structured/internal/experimental/allocator_experimental.go#L135) and can keep using [`constraint` interface](https://github.com/kubernetes/kubernetes/blob/v1.34.2/staging/src/k8s.io/dynamic-resource-allocation/structured/internal/experimental/allocator_experimental.go#L703-L712). We will just extend the current [`matchAttributeConstraint`](https://github.com/kubernetes/kubernetes/blob/v1.34.2/staging/src/k8s.io/dynamic-resource-allocation/structured/internal/experimental/allocator_experimental.go#L721C6-L728) and [`distinctAttributeConstraint`](https://github.com/kubernetes/kubernetes/blob/v1.34.2/staging/src/k8s.io/dynamic-resource-allocation/structured/internal/experimental/constraint.go#L34-L41) instances. Or, we could introduce `constraint` instances for proposed modes (e.g., `nonEmptyIntersectionMatchAttributeConstraint`, etc.).

		#### Story 2

		T.B.D.

Conversation

everpeace commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

k8s-ci-robot commented Nov 19, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

everpeace Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jpbetz Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dom4ha commented Feb 11, 2026

Uh oh!

johnbelamaric commented Feb 11, 2026

Uh oh!

everpeace left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

everpeace Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dom4ha left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

everpeace Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

everpeace left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

everpeace commented Nov 19, 2025 •

edited

Loading

everpeace Feb 11, 2026 •

edited

Loading

jpbetz Feb 11, 2026 •

edited

Loading

everpeace Feb 11, 2026 •

edited

Loading

everpeace Feb 12, 2026 •

edited

Loading

everpeace left a comment •

edited

Loading

everpeace Feb 12, 2026 •

edited

Loading

everpeace commented Feb 12, 2026 •

edited

Loading