KEP-5007: DRA Device Binding Conditions

[KobayashiD27]

• One-line enhancement description: Some network- or fabric-attached devices need to be attached to a node before a pod using them can be scheduled.

• Issue link: DRA: Device Binding Conditions #5007

• Other comments:

[k8s-ci-robot]

Hi @KobayashiD27. Thanks for your PR.

I'm waiting for a kubernetes 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-sigs/prow repository.

[KobayashiD27]

@pohly
I have drafted the KEP. I would appreciate it if we could discuss it further.

[KobayashiD27]

Hi @pohly,
When you have a moment, could you please take a look at my proposal?

CC: @towca @hase1128
Since this is related to CA and DRA, I would appreciate it if you could also review it when you have the chance.

Thank you!

[pohly]

/ok-to-test

I'm a bit time-constrained right now. Not sure whether I can review for 1.33.

[wojtek-t]

@x13n - FYI

[hase1128]

@pohly
I understand your situation. Is there anyone else who might review it?
Should we explain KEP at the regular meeting of wg-device-management?

[pohly]

Discussing it in the meeting would be a good first step to get more people on board.

[zvonkok]

/cc @zvonkok

[KobayashiD27]

I have implemented an experimental version of this DRA scheduler feature. I hope it will be useful for your review.

KobayashiD27/kubernetes@74e2ab9

[KobayashiD27]

@dom4ha We modified the KEP to pass the pull-enhancements-verify. So would you please add lgtm again?
@alculquicondor SIG-Scheduling reviewers and DRA maintainer consider this KEP should be allowed to proceed as an alpha, so please add approve label.

@hase1128 there are still some unresolved comments, please resolve those issues first. For example, the naming and types of some fields, and the need to copy over all the "as-was" fields.

I would also like to retitle this KEP to represent more succinctly what it does. What do you think about something like "DRA: Device Binding Conditions"? That is more accurate, rather than naming it after the specific use case.

@johnbelamaric
Thank you for pointing that out. It appears I had a misunderstanding regarding the usage for "Gates" and "Condition." I have revised the document to reflect the reviews.

[pohly]

API review: some small gaps in the mechanics (+listType) and suggestions to make the API description a bit more complete.

[pohly]

Suggested change

	// If the timeout period is exceeded before all BindingConditions reach a True state, the scheduler clears the allocation in the ResourceClaim and reschedules the Pod.
	// If the timeout period is exceeded before all BindingConditions reach a True state, the scheduler clears the allocation in the ResourceClaim and reschedules the Pod.
	//
	// The default timeout if not set is 10 minutes.

[pohly]

One could argue that this should be set via defaulting, but then we get that value set also when there aren't any binding conditions, or need to be very (too!) clever with the defaulting.

[pohly]

Suggested change

	// +optional
	// The default timeout if not set is 10 minutes.
	//
	// +optional

[KobayashiD27]

Thank you for your review. I have reflected all of your suggestions and comments.

[dom4ha]

/lgtm

[sanposhiho]

/lgtm
for alpha, per the discussion. We need more in-depth discussion later, especially when it's proceeding for beta.

(FYI, I'll be taking two days off from tomorrow, so feel free to DM me on Slack, or just skip me if that's something not critical. I've joined only a few discussion here in this PR, so likely there would be nothing such though)

[pohly]

/assign @alculquicondor

For SIG Scheduling approval. For reviews, see #5012 (comment) (@sanposhiho), #5012 (comment) (@dom4ha) and #5012 (comment) (summary by @dom4ha).

PRR is done and only needs final approval, see #5012 (comment).

[alculquicondor]

/approve
for SIG Scheduling, based on the discussions during the last meeting.

[hase1128]

@alculquicondor
Thank you for your approval.

@johnbelamaric
Please add approval label as PRR approver.

[johnbelamaric]

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alculquicondor, johnbelamaric, KobayashiD27, pohly

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

The pull request process is described here

Needs approval from an approver in each of these files:

• keps/prod-readiness/OWNERS [johnbelamaric]
• keps/sig-scheduling/OWNERS [alculquicondor,johnbelamaric]

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

[hase1128]

@johnbelamaric @pohly @klueska

I too am wary of this. I would like to think about if there is a better way. But all this KEP actually contains right now is the ability to gate binding on conditions. The modification of ResourceSlices as described here is not actually part of the KEP; it's part of the specific implementation of the driver.

So, I think we can proceed with an alpha of the condition-based gating of binding.

I will create a separate issue about this(updating ResourceSlices). Please let me discuss it there.