8363a459bf
mara: "only the abstract jobq part was asked for in the first place" — the previous revision still carried the full hive-c0re step-kind table under a "core-specific nodes" heading; that catalogue belongs in coordinator.md (where it already lived) alongside the rest of hive-c0re's job-queue internals, not duplicated here. jobq.md is now just the domain-agnostic model (graph of steps + shared resource slots) plus the generic row/step/glyph framing for watching it in the dashboard — no hive-c0re-specific step names anywhere. Coordinator.md's job-queue section, docs/README.md, and the root CLAUDE.md reading-paths index are updated to match.
52 lines
2.8 KiB
Markdown
52 lines
2.8 KiB
Markdown
# The job queue, for operators
|
|
|
|
Every container operation — rebuild, first-spawn, a config-PR deploy,
|
|
power changes — runs through one shared job queue. This page explains
|
|
what the job queue *is*, as a general idea, independent of what any one
|
|
subsystem uses it for. For the hive-c0re-specific step catalogue and the
|
|
engineering internals (scheduler, leases, resource windows) see
|
|
[`coordinator.md`](coordinator.md) instead.
|
|
|
|
## What the job queue is, in the abstract
|
|
|
|
"jobq" is a generic engine for running many interdependent jobs under
|
|
limited concurrency — it has no idea what a "container" or a "rebuild" is.
|
|
Two ideas are all there is to it:
|
|
|
|
- **A job is a small graph of steps**, not one opaque blob. Steps can
|
|
depend on each other (this step only starts once that one finishes), so
|
|
a big operation is really a short, ordered sequence — not a single
|
|
black box that's either "done" or "not done."
|
|
- **A step can need a shared resource**, which only so many steps can hold
|
|
at once (a "slot"). If every currently-running step already holds the
|
|
slots it needs, a new step that wants the same one waits its turn —
|
|
that's the whole reason things queue instead of all firing at once.
|
|
|
|
The engine's whole job is: whenever a step's ordering and resource needs
|
|
are both satisfied, run it. It has no opinion on what the steps *do* —
|
|
that's supplied by whoever builds the graph. hive-c0re is the one thing
|
|
building graphs on it today, but nothing about the engine is specific to
|
|
containers or rebuilds; there's nothing stopping another subsystem from
|
|
using the same engine for its own unrelated queue.
|
|
|
|
## Watching it happen
|
|
|
|
Each **row** you see in a queue view (the **BU1LDS** page's R3BU1LD QU3U3
|
|
— see [`web-ui/dashboard.md`](web-ui/dashboard.md) — and swarm-ui's
|
|
`/jobs` page both render the same underlying graph) is one job; the rows
|
|
nested under it are that job's steps, in order (occasionally a couple run
|
|
side by side). A step shows one of:
|
|
|
|
| Glyph | Meaning |
|
|
| ----- | -------------------------------------------------------- |
|
|
| `⏸` | queued, waiting its turn |
|
|
| `▶` | running |
|
|
| `◐` | its own work is done, waiting on a step nested under it |
|
|
| `✔` | finished successfully |
|
|
| `✖` | failed |
|
|
| `⊘` | cancelled |
|
|
| `·` | skipped (not needed for this run) |
|
|
|
|
A step that isn't needed for a given run shows as `·` rather than being
|
|
left out of the tree entirely, so the same kind of operation keeps a
|
|
recognizable shape run to run, whichever steps it actually needed.
|