🤖 AI text below 🤖
Elevator pitch
Expose reliable provider facts without confusing the ability to queue a job, execution readiness, session access, or scheduler admission policy.
Current state
QDMI_DEVICE_PROPERTY_ACCEPTINGJOBS is one candidate. Its boolean shape and mapping are design inputs, not a settled 1.4 contract. A provider may accept work outside an execution window.
Work and decisions
- Use the Core availability design and provider studies to define the smallest facts clients need.
- Separate device status, queue information, submission acceptance, execution windows, and principal/project/reservation context.
- Specify unknown, unsupported, permission failure, timeout, freshness, and snapshot semantics without promising a reservation.
- Decide whether the existing interface suffices before adding properties.
- Record the C11 API and Client/Device ownership only after the design is agreed, then add examples/templates/conformance coverage.
Dependencies and release boundary
Parent design: 💡 Design QDMI availability-based Slurm scheduling. Braket: 💡 Map Braket submission and execution-readiness facts. IQM: 💡 Map IQM access and availability facts for scheduler design.
Acceptance and validation
- A decision record includes cases where submission is accepted but execution is delayed, and where one principal’s access says nothing about another’s.
- Error codes preserve meaningful permission/provider failures instead of collapsing all failures into unsupported metadata.
- The eventual contract has size-query and invalid-handle tests plus positive/negative/unknown cases.
- Non-blocking QDMI 1.4 candidate; absence must not block static licenses or the existing access/status check.
Non-goals
Scheduler policy in QDMI; granting reservations; mandating the previously proposed boolean; 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.
🤖 AI text below 🤖
Elevator pitch
Expose reliable provider facts without confusing the ability to queue a job, execution readiness, session access, or scheduler admission policy.
Current state
QDMI_DEVICE_PROPERTY_ACCEPTINGJOBS is one candidate. Its boolean shape and mapping are design inputs, not a settled 1.4 contract. A provider may accept work outside an execution window.
Work and decisions
Dependencies and release boundary
Parent design: 💡 Design QDMI availability-based Slurm scheduling. Braket: 💡 Map Braket submission and execution-readiness facts. IQM: 💡 Map IQM access and availability facts for scheduler design.
Acceptance and validation
Non-goals
Scheduler policy in QDMI; granting reservations; mandating the previously proposed boolean; 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.