Steps to reproduce
On the verda backend, spot offers are incorrectly marked NOT_AVAILABLE whenever the on-demand variant of the same instance type is unavailable. Because provisioning requests offers with exclude_not_available=True, these spot offers are dropped and never provisioned. Observed with B200 spot instances.
Steps to reproduce
- Configure a verda backend.
- Provision a B200 spot instance, e.g. dstack apply -f task.dstack.yml --backend verda --gpu B200 --spot (B200 available as spot but not on-demand).
- No offers are provisioned. In dstack offer --backend verda --gpu B200 --spot, B200 spot shows as "not available".
Root cause
VerdaCompute._get_offers_with_availability calls get_availabilities() without is_spot (returns on-demand inventory only) and keys the availability map by
(instance_name, region), ignoring spot. Spot offers therefore inherit on-demand availability.
Expected
Spot offers reflect spot inventory availability.
Actual behaviour
No response
Expected behaviour
No response
dstack version
0.20.22
Server logs
Additional information
No response
Steps to reproduce
On the verda backend, spot offers are incorrectly marked NOT_AVAILABLE whenever the on-demand variant of the same instance type is unavailable. Because provisioning requests offers with exclude_not_available=True, these spot offers are dropped and never provisioned. Observed with B200 spot instances.
Steps to reproduce
Root cause
VerdaCompute._get_offers_with_availability calls get_availabilities() without is_spot (returns on-demand inventory only) and keys the availability map by
(instance_name, region), ignoring spot. Spot offers therefore inherit on-demand availability.
Expected
Spot offers reflect spot inventory availability.
Actual behaviour
No response
Expected behaviour
No response
dstack version
0.20.22
Server logs
Additional information
No response