[Bug]: idle_duration: off causes no offers if fleet has idle_duration set

[james-boydell]

Steps to reproduce

• create elastic fleet with idle_duration set to 5m
• attempt to start a run with idle_duration set to off

Actual behaviour

no offers

Expected behaviour

offer should be presented with the lower of the idle_duration between the fleet and the run. In this case, it should have an offer duration of 5m.

dstack version

0.20.11

Server logs

Additional information

No response

[r4victor]

@james-boydell, it's intentional that if runs disable idle_duration, then the fleets with idle_duration enabled are skipped, so that only the fleets with idle_duration disabled are used for provisioning the run.

I can see why you'd expect to have fleet picked up with idle_duration: 5m if you see the effective idle_duration as min(5m, infinity). But why would you want to provision the run with idle_duration: off in that case?

[james-boydell]

We wouldn't want to actually provision a run with idle_duration: off.

The scenario is, an admin or project owner sets up the elastic fleet with idle_duration: 5m to minimize idle instances and reduce costs.

Users then attempt to submit a run with idle_duration: off , which results in no offers. The user doesn't necessarily know that idle_duration was configured on the fleet. They don't understand why there are no offers. The user is blocked and must reach out to an admin to help troubleshoot. It took some trial and error to figure out that it was indeed idle_duration that was causing no offers.

[r4victor]

@james-boydell, understood. Overall I think what you expect is semantically correct and we can change the current logic of skipping the fleets.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.