Leave a unit alone when another declared service still holds it (hq issue 190) #26

2026-10-05T20:22:48Z

mesh-admin commented

2026-10-05 20:22:48 +00:00

Confirming the issue 190 handover (the overlay's registry-trust record goes, docker's daemon adds the same insecure-registries member, in one apply):

The list member is never lost. Orphans are removed before anything is applied (removeOrphans runs before the first resource), so the overlay's record gives its member back first, and docker's addMembers then finds it missing, adds it and records it as docker's. One reload of docker.service (docker.runtime's reload-on), nothing between. Already the behaviour; now pinned by TestTheRegistryMovesToTheRuntimesModuleWithoutLeavingTheList.
Found a real hazard on the same move: removing the overlay's registry-trust-reload record gave back what that record found. A record that found docker.service stopped/disabled would systemctl stop + disable the runtime (every container with it, unless live-restore), only for docker.runtime to start it again in the same apply. Fix: an orphan service whose unit (scope/user/unit) another declared service still holds with a state is forgotten, not given back; the plan preview says the same. The test fails without the fix (stop + disable issued).

Merge order: independent of the code paths in mesh-controller #62 and mesh-catalog #72, but should be deployed before the third issue-190 PR (controller removes the overlay's resources).

gofmt/vet clean, go test ./... passes.

Confirming the issue 190 handover (the overlay's `registry-trust` record goes, docker's `daemon` adds the same `insecure-registries` member, in one apply): - **The list member is never lost.** Orphans are removed before anything is applied (`removeOrphans` runs before the first resource), so the overlay's record gives its member back first, and docker's `addMembers` then finds it missing, adds it and records it as docker's. One reload of `docker.service` (docker.runtime's `reload-on`), nothing between. Already the behaviour; now pinned by `TestTheRegistryMovesToTheRuntimesModuleWithoutLeavingTheList`. - **Found a real hazard on the same move:** removing the overlay's `registry-trust-reload` record gave back what *that* record found. A record that found `docker.service` stopped/disabled would `systemctl stop` + `disable` the runtime (every container with it, unless live-restore), only for `docker.runtime` to start it again in the same apply. Fix: an orphan service whose unit (scope/user/unit) another declared service still holds with a state is **forgotten**, not given back; the plan preview says the same. The test fails without the fix (stop + disable issued). **Merge order:** independent of the code paths in mesh-controller #62 and mesh-catalog #72, but should be deployed before the third issue-190 PR (controller removes the overlay's resources). gofmt/vet clean, `go test ./...` passes.

mesh-admin added 1 commit 2026-10-05 20:22:48 +00:00

Leave a unit alone when another declared service still holds it (hq issue 190) c9001abdb4

Removing one record of a unit gave back what that record found, even while another declared
service holds the unit: when the private network's docker.service record goes and the docker
module's stays, a record that found the runtime stopped would stop it, and every container with
it, only for the docker module to start it again in the same apply. The record is forgotten
instead, and the plan says so. A test pins the registry member moving from the network's record
to the docker module's in one apply without leaving the list.

jschoubben added 1 commit 2026-10-05 20:27:33 +00:00

Keep unitKey's comment on unitKey f0f5873202

mesh-admin merged commit a192bccf62 into main

2026-10-05 20:31:33 +00:00

mesh-admin deleted branch test/190-into-json-member-handover

2026-10-05 20:31:33 +00:00

mesh-admin referenced this pull request

2026-10-05 21:44:52 +00:00

Hand a whole file to its new owner instead of removing it first (hq ADR 0223) #27

mesh-admin commented

2026-10-06 23:10:48 +00:00

Delivery novox/mesh-host@a192bccf62d9 — held since 2026-10-06T23:05:28Z

Held for a person: merged without a passing check: only a person decides that it goes on — mesh-delivery.release with why lets it go on.

Delivery plan — builds mesh-host → ace, g14, novox, shanks; no bus step

tier 0: mesh-host
ace: receives mesh-host
g14: receives mesh-host
novox: receives mesh-host
shanks: receives mesh-host

Transitions

2026-10-06 23:05 (new) → proposed (announced): novox/mesh-host#26 merged; its head was not heard by this owner, so it is made from the forge's word
2026-10-06 23:05 proposed → held (merged-unchecked): merged without a passing check — a verdict known with it is taken first: only a person decides that it goes on

The commit's note under refs/notes/mesh-plan keeps every transition: git log --notes=mesh-plan.

**Delivery** `novox/mesh-host@a192bccf62d9` — **held** since 2026-10-06T23:05:28Z Held for a person: merged without a passing check: only a person decides that it goes on — `mesh-delivery.release` with why lets it go on. **Delivery plan** — builds mesh-host → ace, g14, novox, shanks; no bus step - tier 0: mesh-host - ace: receives mesh-host - g14: receives mesh-host - novox: receives mesh-host - shanks: receives mesh-host **Transitions** - 2026-10-06 23:05 (new) → proposed (announced): novox/mesh-host#26 merged; its head was not heard by this owner, so it is made from the forge's word - 2026-10-06 23:05 proposed → held (merged-unchecked): merged without a passing check — a verdict known with it is taken first: only a person decides that it goes on The commit's note under `refs/notes/mesh-plan` keeps every transition: `git log --notes=mesh-plan`.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-host#26