diff --git a/REPORT.md b/REPORT.md index 0d6a66d..bb50e85 100644 --- a/REPORT.md +++ b/REPORT.md @@ -1,28 +1,20 @@ -# REPORT — v0.342.0 released: the upload and CPU watch, the tested line, qBittorrent's limit (2026-10-24) +# REPORT — the line test for a box that seeds all day (R-1250), 2026-10-24 (attended) -Task: the attended release brief (operator rulings 2026-10-24 07:22 / 07:26: D41 = 50 %, D42, the weekly iperf3 line -test). Design: felhom.eu `architecture/08-alarm-ladder.md` §9; the spike `audits/SPIKE-upload-watch-2026-10-23.md`. +Brief: „two DooPlex backup alarms …", Part 4 (commit only; the release rides the next normal train). Design: felhom.eu +`architecture/08-alarm-ladder.md` §9 item 5. Commit `046b808` (CI 2287 success). Not released, no image built. -## What changed since last night's build - -- The controller reads the host's weekly line test from the agent (`GET /host/line-test`, agent ≥ 0.164.0; - `agentapi.LineTest`): qBittorrent's limit is 50 % of the TESTED line only, the watch judges against the higher of test - and push floor, the system page names the source (`ed1011b`). The start line's wording (`42cda07`). -- MinAgent stays **0.158.1** — an older agent answers 404, read as „not measured" (no limit, the floor stays). - -## Release (the normal path) - -1. `0.342.0-rc.2` on scratch 9202: healthy, the watch started (9202 has no local API, so no line there — by design). -2. `0.342.0` built and pushed (sha256:d002d3b7…); per-customer floors for Tester 1, demo-hp, demo-felhom (08:05:59Z, - 303 `floor_set`); all three healthy on 0.342.0 by 08:08Z; 0 unhealthy, 0 restarting, 0 errors; https-only rc 0. -3. Each box read its tested line at start: Tester 1 94.3, demo-hp 94.4, demo-felhom 92.6 Mbit/s. -4. demo-felhom's qBittorrent (unlimited before): limit **5 789 696 B/s (46 Mbit/s = 50 %)** at 08:20:56Z — the log, - qBittorrent's own `GlobalUPSpeedLimit=5654` KiB/s and the box's record agree. -5. The global floor: on the operator's yes, after this commit (own save). - -Evidence: felhom.eu `documentation/audits/line-test-2026-10-24/controller-0342-boxes.txt`. - -## Not shown live - -The family's line on qBittorrent's page (the household's password is not CC's); pinned by -`TestUpwatch_QBLimitLineOnQBittorrentsPageOnly`. +- **What:** when the agent says the weekly test is due and waits only for quiet, and qBittorrent or Transmission runs, + the controller records the app's upload limit first, holds the app at 1 KiB/s, asks the agent for a test on request, + then puts the exact old limit back. Deferred release; a failed hold is undone first; a household change during the + test stays; an unreachable app keeps the record; a killed controller's start-up check puts it back; the 50 % rule + waits while a record exists. `agentapi.LineTestRun` (own 2-minute timeout via `postSlow`); Transmission's RPC shared. +- **Tests:** 13 new (CHANGELOG lists them), each seen failing: seven hold rules broken one by one, the slow POST, the + start-up order, the wiring of both agent calls. +- **Live (demo-hp, endpoint level, probes from this commit and agent `1e087bb`):** a real 10 Mbit/s seed from scratch + guest 9202 to DooPlex's qBittorrent. Without the hold the agent refused (`not-quiet`, 11.1 Mbit/s). With it the uplink + fell to 0.02–0.16 Mbit/s, the test read 94.2 Mbit/s, the hold lasted 56.8 s, and qBittorrent was back at 1 249 280 B/s + exactly. A `kill -9` in the middle left the record and the 1 KiB/s; the start-up check put the limit back. The pinned + agent client is unit-tested only (the probes spoke plain HTTP). Evidence: felhom.eu + `audits/dooplex-alarms-2026-10-24/part4-r1250-live-proof.txt`. +- **Teardown:** the probe and its store removed from 9202's controller container; qBittorrent removed through the product. +- **MinAgent:** 0.158.1 unchanged (an older agent never reports `waiting_for_quiet`, so nothing is held). diff --git a/controller/README.md b/controller/README.md index e469015..f5a9994 100644 --- a/controller/README.md +++ b/controller/README.md @@ -3538,6 +3538,14 @@ best 10 s). The watch judges against the higher; the system settings page names upload limit of 50 % of the TESTED line only (D41; no test yet → no limit; never over a household's own limit), and its page says so in one line. State: settings.json `upwatch`. Spike: felhom.eu `audits/SPIKE-upload-watch-2026-10-23.md`. +**A box whose torrent app seeds all day** (unreleased, R-1250; `internal/upwatch/linehold.go`): the agent's test needs 10 +quiet minutes, which such a box never gives. When the agent reports `waiting_for_quiet` (agent ≥ 0.165.0) and +qBittorrent or Transmission runs, the 15-minute tick writes `upwatch.line_test_hold` (the app's limit as the app stored +it), holds the app at 1 KiB/s (Transmission 1 kB/s), calls `POST /host/line-test/run` (about 55 s) and puts the old limit +back — the household's own included; a change made during the test stays. A killed controller puts it back at start +(`RecoverHold`, before any rule); the 50 % rule skips while a record exists. Proven on demo-hp with a real seed (felhom.eu +`audits/dooplex-alarms-2026-10-24/`). + ### 8d. Storage that knows its physical disks — the internal place, partitions (v0.317.0 build A, v0.318.0 build B) Design: felhom.eu `architecture/16-storage-physical-identity.md`. The host agent decides which physical disk a place sits on;