feat: the Instance menu offers an overlay network screen, this node only #13

Merged
marcos-mendez merged 4 commits from feat/overlay-screen into master 2026-09-30 03:47:35 -03:00
marcos-mendez commented 2026-09-30 02:56:06 -03:00 (Migrated from github.com)

The console half of step 2 of handbook decision 0020. It adds an Overlay network (WireGuard) entry to the Instance menu. The keel half is Keel-Linux/keel#49; this screen needs keel 0.11.

What the screen does

  • It opens on this node's public key, overlay address, listen port and peers. The public key comes from keel network wireguard key, which makes the key pair on first use, on this machine, and prints only the public key.
  • Address: this node's overlay address and port. The first time, the field is prefilled with keel network wireguard suggest-address (a random ULA, ::1 on its /64). Other nodes take ::2, ::3 on the same /64. Add and Remove appear once an address exists.
  • Add peer: the other node's public key, its overlay address (written as a /128 in allowed_ips), its endpoint ([2001:db8::20]:51820, blank if that node reaches this one) and a keepalive (25 by default). A peer whose key is already listed is replaced.
  • Remove peer: choose the peer by its key; the screen asks before removing it.
  • The screen configures THIS node only. The other node adds this one from its own console.

How a change is applied

  • The screen stages the description, runs keel spec validate and commits it, as the database screens do. Then it runs keel spec apply --system-only --defer-certificate. Unlike the database screens (#12), it does not pass --skip-network: bringing the overlay up is what it is for.
  • An invalid value leaves the description unchanged, and the screen shows keel's own errors.
  • When apply leaves a change waiting, the screen says the change reverts on its own unless confirmed from a new session, over the overlay or the uplink.
  • The screen then offers to run keel network confirm from here. keel accepts that from a real console, and refuses it from an SSH session opened before the change (decision 0018).

Tests

  • wgcli.py and wgscreen.py at 100% (gate 100). The measured package list gains both. 543 tests after merging master (#12); the changelog entry is 2.2.3+keel6.
  • FakeConsole.menu answers from a menus queue when a test scripts one. It still fails when a test opens a menu it did not script.
  • Descriptions built by the screen pass the real keel spec validate of keel#49. Bad values (port, key, endpoint without brackets, address, keepalive) are each reported by keel. These two tests run when keel 0.11+ is on PATH or named by KEEL; otherwise they skip.
  • CI green
The console half of step 2 of handbook decision 0020. It adds an **Overlay network (WireGuard)** entry to the Instance menu. The keel half is Keel-Linux/keel#49; this screen needs keel 0.11. ## What the screen does - It opens on this node's public key, overlay address, listen port and peers. The public key comes from `keel network wireguard key`, which makes the key pair on first use, on this machine, and prints only the public key. - **Address**: this node's overlay address and port. The first time, the field is prefilled with `keel network wireguard suggest-address` (a random ULA, `::1` on its /64). Other nodes take `::2`, `::3` on the same /64. Add and Remove appear once an address exists. - **Add peer**: the other node's public key, its overlay address (written as a /128 in `allowed_ips`), its endpoint (`[2001:db8::20]:51820`, blank if that node reaches this one) and a keepalive (25 by default). A peer whose key is already listed is replaced. - **Remove peer**: choose the peer by its key; the screen asks before removing it. - The screen configures THIS node only. The other node adds this one from its own console. ## How a change is applied - The screen stages the description, runs `keel spec validate` and commits it, as the database screens do. Then it runs `keel spec apply --system-only --defer-certificate`. Unlike the database screens (#12), it does not pass `--skip-network`: bringing the overlay up is what it is for. - An invalid value leaves the description unchanged, and the screen shows keel's own errors. - When apply leaves a change waiting, the screen says the change reverts on its own unless confirmed from a new session, over the overlay or the uplink. - The screen then offers to run `keel network confirm` from here. keel accepts that from a real console, and refuses it from an SSH session opened before the change (decision 0018). ## Tests - [x] wgcli.py and wgscreen.py at 100% (gate 100). The measured package list gains both. 543 tests after merging master (#12); the changelog entry is 2.2.3+keel6. - [x] `FakeConsole.menu` answers from a `menus` queue when a test scripts one. It still fails when a test opens a menu it did not script. - [x] Descriptions built by the screen pass the real `keel spec validate` of keel#49. Bad values (port, key, endpoint without brackets, address, keepalive) are each reported by keel. These two tests run when keel 0.11+ is on PATH or named by `KEEL`; otherwise they skip. - [ ] CI green
Sign in to join this conversation.
No description provided.