Per-node idle-resource-based session allocatability check
- Dominant language
- Python
- Stars
- 670
- Forks
- 183
- Avg merge
- 15h 13m
- Merged PRs (30d)
- 368
Description
Provide a read-only API that determines whether a session can be allocated based on each node's (agent's) idle resources, and reports which resources are insufficient.
## Background
Users currently cannot tell, before creating a session, whether the requested resources fit on any node. We want a lightweight, UI-triggered check that warns (does NOT block) when a session won't fit, and explains which resources are short.
## Behavior
- Given requested resource slots + a scaling group, compute per-node idle resources (available - occupied) and determine whether the session fits on ANY single node.
- Report per-agent fit results; for nodes that do not fit, list which resource slots are insufficient (requested vs available).
- Insufficient slots are ordered by resource_slot_types.rank in REVERSE (rank descending) so scarce/accelerator resources surface first.
## Scope
- IN: resource-only judgement (Case 1: insufficient resources).
- OUT: policy-based blocking (Case 2: keypair/group/domain limits) — deferred until need is confirmed.
- UI-triggered, warning-only (does not block session creation), throttling required.
## Breakdown
- Story 1: scheduling-controller layer — shared fit-check function + check_allocatability method.
- Story 2: API layer — v2 REST + GraphQL + Client SDK + throttling.
JIRA Issue: BA-6562
Contributor guide
Research direction
Start with the scheduling-controller layer and its shared fit-check function, then review the v2 REST, GraphQL, and Client SDK API work described in the breakdown. Confirm the per-node idle-resource calculation, reverse-rank ordering, warning-only behavior, and throttling requirements. Done means the check reports whether any node fits and identifies insufficient resources without blocking session creation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- graphql, python
- Domain
- api, backend, distributed-systems
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100