Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No bid rejection for transient reasons. E.g. no available capacity #3992

Closed
Tracked by #3987
wdbaruni opened this issue May 13, 2024 · 0 comments · Fixed by #4002
Closed
Tracked by #3987

No bid rejection for transient reasons. E.g. no available capacity #3992

wdbaruni opened this issue May 13, 2024 · 0 comments · Fixed by #4002
Assignees
Labels
comp/scheduler Related to job scheduling components

Comments

@wdbaruni
Copy link
Collaborator

wdbaruni commented May 13, 2024

To simplify our scheduling logic and minimize the edge cases and decision branches, I would like us to move to a state where bid rejections by compute nodes are only for terminal reasons and not for transient reasons, such as no available capacity. Compute nodes already queue jobs locally if they don't have immediate capacity, they can share both the available and queued capacity with the orchestrator, and the orchestrator can make a decision on ranking nodes based on those capacities and can filter compute nodes with a large queue and retry later. This enables higher priority jobs to be scheduled in compute nodes with large queue of pending jobs, but get the chance to run sooner if we use priority queues in the executor_buffer

Even if the Orchestrator's view of the network's utilization is stale, we have solutions that can mitigation that including:

  1. Use Sparrow scheduling where the orchestrator will select multiple compute nodes, and they only accept when the job reaches the head of the of the queue and ready to be executed Remove bidding related semantics from compute APIs #3856
  2. Add a Housekeeping task that tracks executions taking too long in negotiation phase and enqueue an evaluation. The scheduler might decide to pick another node if there are better ranked ones or keep the same node otherwise
@wdbaruni wdbaruni self-assigned this May 13, 2024
@wdbaruni wdbaruni added the comp/scheduler Related to job scheduling components label May 13, 2024
wdbaruni added a commit that referenced this issue May 20, 2024
This PR not only closes #3992, but also adds a node ranker based on
available and queued capacity, which we didn't have before. I had to
introduce the ranker along with this PR to make sure some tests are
passing that were relying on bid rejection due to exceeding resource
limits, specifically `TestParallelGPU`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comp/scheduler Related to job scheduling components
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant