b894f1bbc5
The course's documents join the version contract. The course as kept and as served (wai.quantum.course/1) and each exercise (wai.quantum.exercise/1) move from course/schema/ to the crate's schemas/, named and versioned as the rest; a check, a lesson as served and a hint are wai.quantum.course-check/1, and a check now names its engine beside its schema; the command line's progress file is wai.quantum.learn-progress/1. The engine's test holds the course, every exercise, every lesson in each locale and a check and hint of some to them; the learn test holds the progress file; the contract workflow requires both, and the eval and lease tests, by name, and runs when the answer and eval sets its tests read change. The docs runner reads every page the branches added: the error-correction page, the version policy, the deprecations page, the service's self-hosting, scheduler and provenance pages, and the views' README. Each block the other branches wrote either runs or says why it cannot (a sweep fixture added), and the job service it starts keeps its store in its scratch. The crate's README names wai-quantum 0.7. The Chinese READMEs hold the English pages' code again: the sections for error correction, sets and sweeps, the service's dry runs, the scheduler, scoring a model, the answer layer, views and versions are translated, and the compile pages name the gate set basis. The command line's Chinese words cover task, qec, eval and version, and submit as it reads now. The documentation index links the policy, the deprecations, the error-correction page and the service's pages in both languages. The policy lists every schema file and says the answer layer is a draft outside its promise. The 0.7.0 heading names what the four branches bring. The views page bundles the Studio components that now read their words through the locale module; build-views.mjs gives it the English words alone, so no other language's words reach a host. The result parts the Studio and the views share read their words through it too, so the Studio's result pane stays translated, its English unchanged. Co-Authored-By: Claude Opus 5.5 <[email protected]>
4 KiB
The job service as a scheduler's resource
An on-premises batch scheduler, or a resource-management interface in front of one, can hand the job service to its batch jobs as a resource, the way it hands out processors or accelerators. The command line's wai-quantum task is the adapter. It follows the shape these interfaces share, described here by function:
| function | wai-quantum task … |
what it does |
|---|---|---|
| describe the resource | target |
the service's methods, limits, store, metering and receipt keys, as JSON |
| check it is accessible, and acquire it | acquire |
checks the service is healthy and takes this client now, and opens a lease (exit 69 if not) |
| start a task | start JOB.json |
submits a job or a set under the lease, prints its id |
| a task's state | status ID |
queued, running, done, failed, cancelled or interrupted (exit 0 done, 1 ended otherwise, 2 still active) |
| wait for a task | wait ID |
follows it to its end, each state on standard error |
| a task's result | result ID |
its request and result as JSON, the receipt checked first (exit 1 if it does not verify) |
| stop a task | stop ID |
cancels it |
| release the resource | release |
stops every task of the lease still queued or running, and closes it |
The exit statuses follow the sysexits convention batch scripts test for: 65 a job file that does not read, 69 the resource unavailable or refusing, 75 a refusal to retry later (the client's limits, a full queue).
The lease
The lease is a file: --lease, or WAI_QUANTUM_LEASE, by default wai-quantum-lease.json in the working directory. It names the service, the moment it was acquired, the service's receipt key and limits then, and every task started under it. The service itself holds no reservation: the lease is the adapter's record of what one allocation started, so that releasing it stops exactly those tasks.
Wiring it to a scheduler
A scheduler runs a prologue before a batch job starts and an epilogue after it ends, however it ends. Point both at the adapter, and give the job the service's address (and, for a private deployment, its key) in its environment:
# prologue, before the batch job: the resource must be there, and take this client
export WAI_QUANTUM_SERVICE=https://quantum.example.org/quantum-jobs
export WAI_QUANTUM_LEASE="$JOB_DIR/wai-quantum-lease.json"
wai-quantum task acquire || exit 69
# the batch job
id=$(wai-quantum task start sweep.json)
wai-quantum task wait "$id"
wai-quantum task result "$id" > result.json # checked against its receipt first
wai-quantum verify result.json # and again, by anyone, later
# epilogue, after the batch job, however it ended: no task outlives the allocation
wai-quantum task release
sweep.json is any job the service takes. A set or a sweep runs as one task, one result per item and one receipt binding them, so a parameter scan is a single task, not one per point:
{ "qasm": "OPENQASM 3.0;\ninput float theta;\nqubit[2] q;\nrx(theta) q[0];\ncx q[0], q[1];\n",
"sweep": { "theta": [0.0, 0.25, 0.5, 0.75, 1.0] },
"observables": ["Z0 Z1"] }
Before committing an allocation to it, a job can be planned without running: wai-quantum submit prog.qasm --dry-run gives the method, the memory, the estimated time and energy with their basis, the bounds that apply, and whether the service would take it now.
Limits and keys
The public service counts a client by its address. A batch system submits from a few login or compute nodes on behalf of many people, so on a shared deployment give the scheduler its own API key (WAI_QUANTUM_API_KEY, see self-host.md). Its limits are then counted by the key's name, and WAI_QSVC_CLIENT_ACTIVE, WAI_QSVC_CLIENT_GB and WAI_QSVC_CLIENT_BURST size them. Every answer carries the client's submission window in RateLimit-Policy and RateLimit, and a refusal past it carries Retry-After. The adapter exits 75 on such a refusal, which a scheduler can treat as "requeue".