v0.12.0

A job now starts if it fits now and will still fit beside every job ahead of it when that one starts: waiting jobs no longer set aside cores and resources for later, so checks run in room that set-asides used to keep empty, with the same promise that no job is delayed by jobs that got in line after it. status --json gives tools a documented format.

Changed

• The admission rule. A job decides from the jobs ahead of it alone, so no job is delayed by the jobs behind it; what the rule protects is the limits. A job may start if (1) it fits now beside the running jobs ahead of it and those about to start, and (2) for every job ahead of it that waits, it will still fit beside that job when it starts, next to the most the other jobs ahead could use beside it then. Set-asides, "counts on", and a job short of CPU holding back everyone behind it are gone: all of it follows from (2).
  • Unit runs waiting in turn for the browser a long UI capture holds keep no cores from the checks behind them, however many wait; a second capture waiting behind the first does not hold back the cores left beside it.
  • With CPU alone, a small job may start ahead of a big one that waits, where it cannot be in its way when that one starts. When the big one needs the whole machine, the small one still waits.
  • Running jobs never use more, on any dimension, than the smallest limit any of them records (capacities that repositories or machines record differently). CPU busy outside the queue only throttles starts, as before: jobs that started earlier may keep the machine above the lowered limit, never above the capacity. Measure-only jobs start whatever the rule says, so the promises do not hold while one runs or after one started.
  • The rule was reviewed three times; each counterexample found is a unit test, and the simulations add departures, parked places that resume or expire, jobs that adapt to CPU outside or not, disagreeing limits, and random poll orders.
• Every use of a resource counts in its checkout. A use without a per-checkout limit of its own was left out of its checkout's count, so a run could take a checkout past the limit another task recorded. Fixed.
• Why a job waits (status, the waiting messages): either it does not fit now (3 cores (7 of 8 in use)), or it would not fit beside a start ahead (3 cores (6 of 8 could be in use when #43 `e2e` starts, beside #41 `test`)), naming the job ahead whose record set a smaller limit when there is one. "Sets aside" and "counts on" are gone.
• loadmaster check reports a waiting run as keeping a task out only if the task fits beside the long run the waiting run waits for, but not beside the waiting run's start, and would if the waiting run took one core; the rule itself decides it.

Added

• loadmaster status --json: the queue for tools, in a versioned format documented in the README ("Status as JSON"): capacity, resources, CPU outside the queue, other versions' queues, and per job its state (running, waiting, parked, orphaned, lingering), amounts, limits, processes and why it waits, as data and as the sentence the table shows. Any change to the format will be a breaking change of a release; the table may change in any release.

Breaking changes

• The queue moved to queue-v4.db. Its schema did not change, but the admission rule is the protocol between the processes that share a queue, and 0.11's rule does not protect the new promises. Upgrade every agent on a machine at once (mise use -g github:ktanaka101/loadmaster@0.12.0); until then, status and run say how many jobs run in the old queue, which the new one does not count. Delete queue-v3.db (with -wal and -shm) in ~/.local/state/loadmaster once no 0.9 to 0.11 job runs.
• The reasons in status and the waiting messages are worded differently (see above).

Install

mise use -g github:ktanaka101/loadmaster@0.12.0

Or download the archive for your platform below: macOS (Apple Silicon and Intel) and Linux (x86_64 and arm64, statically linked).