This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

/assign @pohly

In the PR description you claim that it conflicts, but that claim is not supported by an actual explanation why or how.

Let's investigate and find the root cause before making further changes.

/cc @johnbelamaric

the comment in the code provides more details on why there is such conflict

18 minutes after the test finishes, kubelet still publishes 'example.com/resource: "0"' in node.status.Capacity and node.status.Allocatable. I tried to remove it from node.status, but kubelet keeps putting it back. still need to figure out how to cleanly remove it.

while true; do date; kubectl get no -o yaml|grep example; sleep 5; done

Tue Jul 29 08:24:39 PM UTC 2025
example.com/resource: "0"
example.com/resource: "2"
... ... ...
Tue Jul 29 08:42:17 PM UTC 2025
example.com/resource: "0"
example.com/resource: "0"

ok, it failed again, now i need to keep looking into it.

/test pull-kubernetes-kind-dra-all

@pohly @johnbelamaric found out the root cause.

the feature "DRADeviceBindingConditions: true" does not work well with "DRAExtendedResources: true", i think DRADeviceBindingConditions was merged last night? I did not enable it when running the test locally.

360 2025-07-29T23:19:13.141476715Z stderr F panic: runtime error: invalid memory address or nil pointer dereference
361 2025-07-29T23:19:13.141506335Z stderr F [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x193c851]
k8s.io/kubernetes/pkg/scheduler/framework/plugins/dynamicresources.hasBindingConditions-range1(...)
365 2025-07-29T23:19:13.141546435Z stderr F k8s.io/kubernetes/pkg/scheduler/framework/plugins/dynamicresources/dynamicresources.go:1641
366 2025-07-29T23:19:13.141554475Z stderr F k8s.io/kubernetes/pkg/scheduler/framework/plugins/dynamicresources.hasBindingConditions.(*claimStore).all.func1(...) 367 2025-07-29T23:19:13.141564265Z stderr F k8s.io/kubernetes/pkg/scheduler/framework/plugins/dynamicresources/claims.go:72 368 2025-07-29T23:19:13.141584485Z stderr F k8s.io/kubernetes/pkg/scheduler/framework/plugins/dynamicresources.hasBindingConditions(0xc00051e5a0?) 369 2025-07-29T23:19:13.141592225Z stderr F k8s.io/kubernetes/pkg/scheduler/framework/plugins/dynamicresources/dynamicresources.go:1640 +0x51 370 2025-07-29T23:19:13.141610715Z stderr F k8s.io/kubernetes/pkg/scheduler/framework/plugins/dynamicresources.(*DynamicResources).PreBind(0xc00051e5a0, {0x232c588, 0xc0007ef740}, {0x233b410?, 0xc00051f810?}, 0xc000d63688, {0xc000467d30, 0xc}) 371 2025-07-29T23:19:13.141632805Z stderr F k8s.io/kubernetes/pkg/scheduler/framework/plugins/dynamicresources/dynamicresources.go:1312 +0x3d8

So this E2E failure was legitimate and #133290 fixes the problem, and was merged via #132522.

There's still some learnings here: removing the extended resource from node status doesn't really work because of the kubelet. We should update the code accordingly and replace patching the node status with waiting for the count to go to zero or (in case of a future kubelet enhancement) to not be present.

Let's use this PR to implement that? Or file an issue and close the PR.

we can keep using this PR since it has some context already, what needs to figure out is why kubelet keeping publishing the extended resource after device plugin has been removed.

#133488

Should we fix the leak/conflict instead?

These tests could also be marked as serial.

@BenTheElder we should fix the leak, but before that, it is better to comment out the other conflicting test, which was added for testing the deployDevicePlugin, which has already been tested in "must run pods with extended resource on dra nodes and device plugin nodes" test case.

they are already marked as Serial, but that would not help, since the leaked example.com/resouce in the cluster's nodes still interferes with the next test run in the same cluster.

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: yliaog
Once this PR has been reviewed and has the lgtm label, please ask for approval from pohly. For more information see the Code Review Process.

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

/test pull-kubernetes-unit

thet two test failures are not related to this PR, they can be ignored.

they are already marked as Serial, but that would not help, since the leaked example.com/resouce in the cluster's nodes still interferes with the next test run in the same cluster.

Ah ... that's pretty bad, would like to get that fixed.

We usually don't comment out tests, we e.g. [Flaky] or [Serial] or [Disruptive] tag them or delete them outright as appropriate. If deleted they will still be in git. If meant to be only temporarily disabled, Flaky etc works.

framework.WithFlaky() might be an appropriate short-term solution?

ok, added withFlaky() to temporarily disable the test

@yliaog: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.