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.

CC: @ttsuuubasa

/test pull-kubernetes-integration

Does simply moving the startScheduler() to the current location actually guarantee that both ResourceSlices have been created?

First, let’s clarify why the test failed.

If I understand @tsj-30 correctly, the failure happened because the without-binding ResourceSlice had not been created yet (i.e., it wasn’t ready in time), and the ResourceClaim allocation ran while only the with-binding slice existed.
Is that the correct understanding?

If so, it seems necessary to wait until both ResourceSlices are created before creating the ResourceClaim. What do you think?

If I understand @tsj-30 correctly, the failure happened because the without-binding ResourceSlice had not been created yet (i.e., it wasn’t ready in time), and the ResourceClaim allocation ran while only the with-binding slice existed.

Log output of a failed run should be able to confirm that hypothesis. It depends a bit on the log level, though. It would be good to see this, otherwise we make changes without really knowing the root cause.

If so, it seems necessary to wait until both ResourceSlices are created before creating the ResourceClaim. What do you think?

The important part is that the scheduler has to have both slices in its informer cache when it schedules the pod. Running the scheduler and then creating them does not guarantee that. Creating the slices and then starting the scheduler is fine because the scheduler first syncs its caches, then starts scheduling pods.

Log output of a failed run should be able to confirm that hypothesis. It depends a bit on the log level, though. It would be good to see this, otherwise we make changes without really knowing the root cause.

After reviewing the log output, I can NOT say that there was definitive evidence proving the hypothesis.
Between the start of TestDRA/all and the end of DeviceBindingConditions/BasicFlow, there were no clear errors.

However, in a separate ControllerManagerMetrics test, an error occurred when scheduling a Pod, indicating that the DeviceClass did not exist.
Since this DeviceClass should have been created at the beginning of the test, the fact that it was missing suggests that the API server may likewise have been slow to create it.

14:49:34.041314: Started the scheduler for test TestDRA/all.

14:49:34.042580: [ControllerManagerMetrics] device class does not exist

14:49:35.062107: Error in this run

14:49:35.081248: Stopping the scheduler after test TestDRA/all/DeviceBindingConditions/BasicFlow...

How often does this error actually occur?
To verify the hypothesis above, it might be help to log the scheduler’s slice informer cache list right before the corresponding gomega.Expect is executed.

The important part is that the scheduler has to have both slices in its informer cache when it schedules the pod.

So this means that instead of simply checking for existence with a clientset Get against the API server, we need to check for existence using the scheduler’s informer Get?

Creating the slices and then starting the scheduler is fine because the scheduler first syncs its caches, then starts scheduling pods.

I understand the benefit of creating the ResourceSlice before starting the scheduler.
However, isn’t there still a possibility that the ResourceSlice creation on the API server may be delayed, causing the scheduler to start before the slice actually exists, leading to the same kind of issue?

Would it make sense to introduce a helper that verifies whether the scheduler’s informer cache actually contains the specified resource?

I also considered adding such cache checks to the existing helpers like createSlice or createClaim, but that would implicitly assume that the scheduler is already running, which may not hold for all test scenarios, right?

we need to check for existence using the scheduler’s informer Get?

Even if the informer cache has the object, the event handlers might not. The test code might have access to the informer cache (I think it provides the informer factory), but it probably doesn't have access to all event handlers. Starting the scheduler after setting up objects seems easier.

However, isn’t there still a possibility that the ResourceSlice creation on the API server may be delayed, causing the scheduler to start before the slice actually exists, leading to the same kind of issue?

No. Once a Create call returns, any Get or List call will report the new object.

LGTM label has been added.

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: pohly, tsj-30

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

The pull request process is described here

Fixed #133435

For the future: please don't auto-close flake issues in the PR. We want to keep the issue open to verify that the flake is really gone.

Based on the discussion above, I think the proposed changes are fine.

/release-note-none

The "NONE" has to be in the verbatim text block.

@tsj-30: The PR uses some parts of the Kubernetes PR template, but it was modified (sections, verbatim text block). I'm curious: was that done manually or AI generated?

To make the test deterministic, the ResourceSlice without binding conditions is created before the slice with binding conditions, so the initial allocation path consistently matches test expectations.

This part of the PR description is out-dated. Would be nice to update it, for future reference.

Hey @pohly, @ttsuuubasa
Apologies for the delayed response — I haven’t been feeling well the past couple of days and am still recovering.
Thanks for the LGTM 🚀 Really appreciate it!

/release-note-none

The "NONE" has to be in the verbatim text block.

@tsj-30: The PR uses some parts of the Kubernetes PR template, but it was modified (sections, verbatim text block). I'm curious: was that done manually or AI generated?

Yaa, I used AI to help draft the PR description and missed that,
Sorry about that — I’ll fix it right away,
Thanks for pointing it out. 😄