evangelostsak 160b0eaff7 fix(inventory): route the whole pool through the hub from a spoke ...

A spoke's AllowedIPs for the hub was its own mesh subnet, so a worker on
10.100.0.0/24 had no route to the NFS server on 10.100.1.11 and could not
reach the plane it is deliberately not a member of -- which is the entire
reason the hub sits in both.

The symptom would have been misleading: every tunnel reports a healthy
handshake, the gate passes because it only pings peers the host is configured
for, and the failure surfaces later as an NFS mount that hangs. It points at
storage rather than at routing.

Spokes now route the declared pool through the hub while the hub keeps each
spoke pinned to a single address; routing the pool in both directions would
blackhole every member behind whichever spoke came first.

Found by running the writer against the prefixed five-host topology before the
deploy rather than during it.

2026-09-18 16:37:18 +02:00

..

deploy

fix(coredns): answer every record type for the test zone instead of forwarding it

2026-09-12 09:35:58 +02:00

inventory

fix(inventory): route the whole pool through the hub from a spoke

2026-09-18 16:37:18 +02:00

recover

…

__init__.py

…