💡 Design QDMI availability-based Slurm scheduling

🤖 AI text below 🤖

Elevator pitch

Avoid allocating costly cluster resources when useful QPU access is implausible, while keeping provider facts separate from cluster policy. Accepting a queued submission is not the same as executing promptly or granting access to another principal.

Current state

Core #2310 proposed license-only reservations, QDMI #522 proposed an accepting-jobs boolean, and Braket #28 proposed provider mappings. These are design inputs, not settled contracts. Static licenses and optional launch-time checks can ship independently.

Work and decisions

• Define submission acceptance, execution readiness, expected waiting, and administrator admission policy separately.
• Determine whose credentials/project/reservation the monitor observes and when those observations apply to jobs using other identities.
• Specify known-negative, unknown, permission failure, timeout, stale observations, service failure, recovery, and ownership behavior.
• Compare local license-only reservations with other established Slurm mechanisms; do not use Slurm Dynamic Licenses as a generic name for this service.
• Cover running jobs, administrator reservations, polling races, multiple service instances, and QAN/service-node placement.
• Collect QDMI, Braket, and IQM evidence before choosing properties or a synchronizer algorithm.
• Keep #2310 implementation blocked and unscheduled until the design is approved.

Dependencies and release boundary

Independent static work: ✨ Centralize static-license QDMI deployment and optional SPANK injection. Existing design inputs: #2310, https://github.com/Munich-Quantum-Software-Stack/QDMI/issues/522, https://github.com/munich-quantum-software/amazon-braket-qdmi-device/issues/28. This is a design issue; implementation has no committed release milestone.

Acceptance and validation

• A decision record separates facts, policy, credentials, scheduler state, and access control.
• Failure/recovery timelines demonstrate that unknown or stale data does not silently publish a guarantee.
• A Slurm experiment validates the selected mechanism with pending and already-running jobs.
• Child issues identify the smallest generic interface and provider mappings needed, or document why no new property is required.

Non-goals

Blocking static Slurm centralization; promising instantaneous availability or reservations; implementing the current boolean proposal without review; QDMI v2 stack changes.

Required counterexamples

Use explicit counterexamples: a service may accept queued submissions outside an execution window; an online or BUSY device may reject further submissions; an IDLE device may still deny a particular principal. Queue depth and IDLE/BUSY alone do not establish submission acceptance. Distinguish observed provider facts, identity/access, execution readiness, and administrator admission policy. Test unknown/stale observations and recovery without presenting a snapshot as a reservation.

Sub-issues

• 💡 Map IQM access and availability facts for scheduler design
• ✨ Implement Slurm availability synchronization after the design decision
• 💡 Define submission-acceptance and readiness information for clients
• 💡 Map Braket submission and execution-readiness facts