8 Commits

Include renames

Author	SHA1	Message	Date
jschoubben	3d1a450406	pacman starts a round's run only once the node's file holds the round's mirror list, and a refresh never writes after a round opened (ADR 0585 §2, §4; review round 1) ... The opener ranked the list and took its turn in the same step, so its upgrade started before the keeper's change hook wrote /etc/pacman.d/mirrorlist, and a failed write on any node was only logged. A round's run now writes the list first and checks the file holds the revision the round opened with; otherwise the run is refused with why and tried again an hour later, as every refused run is. A refresh asks again for a running round right before its write, since ranking takes minutes. Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL	2026-11-01 16:32:59 +01:00
jschoubben	2b495c4818	pacman keeps one mirror list for the mesh, ranked in the write that opens each round and written by every node (ADR 0585, issue 1876) ... Each node's reflector ranked its own list on its own timer, and on 2026-10-31 one node's lagging first mirror left it a Node.js version behind the rest. The list is now the module's state mirrors, key list: the node that opens a week's round ranks it with the module's reflector options, keeps only mirrors whose last sync is no older than the newest found, and the round's key names the list's revision. Every keeper writes /etc/pacman.d/mirrorlist whole from the key through the root helper's new verb mirrorlist, when the key changes and when the file differs, and never writes an empty or unreadable list. reflector.timer is declared stopped and disabled, and reflector.conf saves nothing. pacman_mirrors answers the shared list, its ranker and age and whether this node's file matches; with refresh it asks this node's keeper to rank again, refused while a round runs, naming it. The round's integration test proves the opening write and both nodes' files. Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL	2026-11-01 16:18:22 +01:00
jschoubben	ac5d257a1c	Let no run read from pacman's log, nor a run whose transaction ended, hold an asked upgrade back; read one run of the addressed machine whole (issue 1841) ... Every run imported from the log ends at finished or failed and is never checked after, so the one-run-at-a-time rule counted each as still going: novox's ask of 2026-10-22 22:00 was refused on its install-time run 20220123T194900Z, and every node holds such runs. The rule now holds back a new run only for a run the mesh ran whose transaction may still go on. pacman_upgrades refused a run without its node, and the console takes node out of the arguments of an address that names the machine, so no run could be read whole: a run without a node is now that machine's.	2026-10-22 22:04:23 +02:00
jschoubben	f339d0aab7	Merge branch 'feat/upgrade-safety' into p2 ... # Conflicts: # modules/pacman/cmd/pacman-tools/main.go # modules/pacman/cmd/pacman-tools/transaction.go # modules/pacman/module.json	2026-10-22 14:44:41 +02:00
jschoubben	43fccb843c	issue 1841/S10: return a node to a run's record, saying first what each package goes back to and from where ... pacman_rollback plans from the bus: each package now -> record from the node's cache, else the archive's exact version, else the archive's repository on the record's date; added packages listed and removed only when asked; foreign packages untouched. apply is an ask the node's keeper runs as a rollback run through the root helper's new Rollback act (RootActs, upgrades.go), with rollback.started, rollback.finished and the after-upgrade check (TakeAsk's rollback case, transaction.go).	2026-10-22 14:44:24 +02:00
jschoubben	f550f1c6b2	issue 1841/S8: upgrade the nodes one at a time in a weekly round in upgrade-order, stopping at a failure and passing a node only on the operator's Approve, so one bad upgrade never reaches every machine	2026-10-22 14:44:17 +02:00
jschoubben	900a2da3e3	issue 1841/S6: check after every upgrade the files it left, the news since the last one, units newly failed and a restart needed, so the operator sees what an upgrade asks of them	2026-10-22 14:37:58 +02:00
jschoubben	95e69276c3	Carry out an upgrade as an ask its node's keeper takes, through the root helper, and follow a run to its end after a restart, so a hand upgrade is a recorded, checked run like any other (issue 1841/S5)	2026-10-22 14:35:19 +02:00