067f4e5699
gateway.md: split the opener into what/audience/enable; vhost map in two tables (swarm-service vhosts declared by their own modules, then the hive vhost) matching vhosts.nix and the service modules; gateway.enable exists and is set with mkDefault by the modules that need it; Basic auth scope, dashboard /health/ prefix, error-page rendering, matrix body limit and forge link source corrected; nginx internals grouped under one Internals section with their headings unchanged. network.md: gateway and dnsmasq run on the host, not in a container; network.enable is set by the modules that need it; shared-netns firewall rule covers every swarm service container; hive-priv writes the nspawn conf; domain sentence rewritten; removed options moved into <details>. jobq.md: swarm-controller runs its own graph; swarm UI /jobs and BU1LDS show different graphs drawn by the same component. observability.md: swarm tier first; history narration cut; network access deduplicated into a link to network.md; options link made absolute. matrix.md: swarm.matrix vs deploy.matrix namespaces; tuning, firewall and SSO options under deploy.matrix; .well-known is served on the hive domain; roadmap sentence deleted; stale hive-c0re provisioning claims fixed; serverName upgrade note moved into <details>. Refs #3902
62 lines
3.1 KiB
Markdown
62 lines
3.1 KiB
Markdown
# The job queue, for operators
|
|
|
|
Long-running work runs through a job graph. The swarm controller keeps one
|
|
for swarm-level work — creating an agent's identity, forge user and config
|
|
repo. Each hive's hive-c0re keeps its own for container operations —
|
|
rebuild, first-spawn, a config-PR deploy, power changes. This page explains
|
|
what the job queue _is_, as a general idea, independent of what either uses
|
|
it for. For the hive-c0re 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. The swarm controller and
|
|
hive-c0re each build their own graph on it, and nothing about the engine
|
|
is specific to either.
|
|
|
|
## Watching it happen
|
|
|
|
Two views, one per graph, drawn by the same component: the swarm UI's
|
|
`/jobs` page shows the swarm controller's graph, and the hive dashboard's
|
|
**BU1LDS** page (R3BU1LD QU3U3 — see
|
|
[`web-ui/dashboard.md`](../web-ui/dashboard.md)) shows that hive's. Each
|
|
**row** 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:
|
|
|
|
<!-- vale write-good.Passive = NO -->
|
|
|
|
| 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) |
|
|
|
|
<!-- vale write-good.Passive = YES -->
|
|
|
|
A step that isn't needed for a given run stays in the graph as `·` rather
|
|
than being absent from it, so the same kind of operation keeps a
|
|
recognizable shape run to run, whichever steps it actually needed.
|
|
|
|
⚠️ **The view hides `✔` and `·` by default**, so that full shape isn't what
|
|
you see first — tick them back on in the state filter. The selection is
|
|
part of the request, not a display toggle: hidden states are never fetched.
|