fix: Keel screens follow the appliance manifest, and fit 80x24 #19

Merged

marcos-mendez merged 3 commits from fix/menus-from-the-manifest into master

2026-10-02 10:58:23 -03:00

marcos-mendez commented

2026-10-02 10:48:11 -03:00

(Migrated from github.com)

What changes

Menus from the manifest (decision 0041). keelmenu.py reads appliance.name and installation.mode from the spec and asks keel to resolve the chain (keel.manifest.facts.gather, the resolution behind keel manifest show --resolved and keel spec validate), so confconsole holds no second copy of the rules.

Entry	Offered when
View, Apply, Show drift, Export spec	always
Database mode	a `mariadb` or `postgresql` data service is in the chain (an overlay that `provides` it, or an application service). Not on Keel Core or Keel Web
Overlay network	`wireguard` is in the chain; in the Instance menu in `cloud_simple`/`cloud_advanced` or once the spec enables or configures the overlay, otherwise behind a new Advanced entry
Keel Cloud	only when `/etc/keel/cloud-endpoint` holds an endpoint; hidden by default

A chain that cannot be read (no keel, no manifests as on pre-0041 images such as the WordPress templates, no appliance.name) keeps the screens as before, the overlay behind Advanced.

Keel Cloud gated. The Instance entry is hidden, run by name it says Keel Cloud is not available, and keelfirstboot.py cloud, which inithooks' 80keel-cloud runs, asks and stores nothing (keel-init and a preseeded HUB_APIKEY included). The screen, its tests and the first boot step stay; writing /etc/keel/cloud-endpoint turns them on. inithooks is not changed: 80keel-cloud only calls keelfirstboot.py cloud, which carries the gate, so there is nothing to merge after inithooks keel17.

Nothing cut at 80x24. keelfit.py: a menu is as wide as its widest choice or text line, a message box as its text, both up to what the terminal leaves (keelbanner.available), so no box is drawn over the backtitle; an item is shortened with an ellipsis only past the full width. Show drift stacks its table two lines a field when it is wider than the box (every row wrapped in two at 80 columns). The overlay screen lists one line a peer, at most three, so its menu keeps its rows (two peers drew the menu over its buttons). The Keel descriptions were shortened and a test holds every Instance menu to 80 columns.

Overlay address wording. The Address form says the suggestion is this node's address on Keel's private mesh, randomly generated, not a LAN address; the first node keeps it, the others take ::2, ::3 on the same /64; the port is the UDP port the other nodes reach.

Found, not changed here

The installed overlay manifests name screens confconsole does not ship: wireguard.yaml has screen: /usr/lib/confconsole/plugins.d/Networking/wireguard.py (the screen is Instance/Overlay_network.py) and crowdsec.yaml has Security/crowdsec.py (no CrowdSec screen exists). The rules here key on the overlay and the engine, not on that path.

Test plan

set -o pipefail; coverage run --branch -m pytest tests: 789 passed, 7 skipped; 100 percent lines and branches over the measured package, which gains keelfit and keelmenu; with keel's library on the path 796 passed (the real-resolution tests run)
confconsole 2.2.3+keel12 built and installed with dpkg on the step 8 Keel Web and Keel Core images in LXC on the test VM; keelmenu.machine() resolves web (core, web) and core with no data engine; keelfirstboot.py cloud skips with and without _TURNKEY_INIT
Every Keel menu and screen captured at 80x24 and 100x30: Advanced Menu, Instance (Web and Core, no Database mode), Advanced, Overlay network with no address and with two peers, Address, Add peer, Remove peer, Apply/Export/Show drift/View spec, Core in cloud_simple (Overlay in the menu), Keel Cloud with the flag on, and run by name with it off
Database mode screens on a MariaDB or WordPress image built with manifests (none of the step 8 images carries a database)

Review follow-ups (`9d80eda`, `1f96eb9`)

/etc/keel/cloud-endpoint must hold one https URL with a host (bracketed IPv6 allowed), in a root-owned regular file not writable by group or others; anything else keeps Keel Cloud hidden and is logged. Format in docs/Instance.rst.
keelfit never passes dialog a size of 0 (tested at 8 columns).
Database mode also shows where the description declares database.server, and for Redis: the engines are one set, keelmenu.DATA_ENGINES = {"mariadb", "postgresql", "redis"}.
Gap, not faked: keel validates primary/replica for Redis (and PostgreSQL) but keel spec apply converges MariaDB only (system/database.py returns a note for any other engine), and keel-redis's boot test expects standalone only. So Redis gets Database mode > Standalone, no Cloud submenu, and the first boot asks it no role. PostgreSQL loses the Cloud submenu for the same reason. Adding an engine to REPLICATING_ENGINES turns it on once keel applies it.

The maintainer's review of the Keel Web step 8 image on Proxmox: Database mode on an appliance with no database, WireGuard in the first menu of a simple installation, a Keel Cloud screen asking for a key nobody can generate yet, and menu descriptions cut at the box edge. ## What changes **Menus from the manifest (decision 0041).** `keelmenu.py` reads `appliance.name` and `installation.mode` from the spec and asks keel to resolve the chain (`keel.manifest.facts.gather`, the resolution behind `keel manifest show --resolved` and `keel spec validate`), so confconsole holds no second copy of the rules. | Entry | Offered when | | --- | --- | | View, Apply, Show drift, Export spec | always | | Database mode | a `mariadb` or `postgresql` data service is in the chain (an overlay that `provides` it, or an application service). Not on Keel Core or Keel Web | | Overlay network | `wireguard` is in the chain; in the Instance menu in `cloud_simple`/`cloud_advanced` or once the spec enables or configures the overlay, otherwise behind a new **Advanced** entry | | Keel Cloud | only when `/etc/keel/cloud-endpoint` holds an endpoint; hidden by default | A chain that cannot be read (no keel, no manifests as on pre-0041 images such as the WordPress templates, no `appliance.name`) keeps the screens as before, the overlay behind Advanced. **Keel Cloud gated.** The Instance entry is hidden, run by name it says Keel Cloud is not available, and `keelfirstboot.py cloud`, which inithooks' `80keel-cloud` runs, asks and stores nothing (keel-init and a preseeded `HUB_APIKEY` included). The screen, its tests and the first boot step stay; writing `/etc/keel/cloud-endpoint` turns them on. **inithooks is not changed**: `80keel-cloud` only calls `keelfirstboot.py cloud`, which carries the gate, so there is nothing to merge after inithooks keel17. **Nothing cut at 80x24.** `keelfit.py`: a menu is as wide as its widest choice or text line, a message box as its text, both up to what the terminal leaves (`keelbanner.available`), so no box is drawn over the backtitle; an item is shortened with an ellipsis only past the full width. Show drift stacks its table two lines a field when it is wider than the box (every row wrapped in two at 80 columns). The overlay screen lists one line a peer, at most three, so its menu keeps its rows (two peers drew the menu over its buttons). The Keel descriptions were shortened and a test holds every Instance menu to 80 columns. **Overlay address wording.** The Address form says the suggestion is this node's address on Keel's private mesh, randomly generated, not a LAN address; the first node keeps it, the others take `::2`, `::3` on the same /64; the port is the UDP port the other nodes reach. ## Found, not changed here The installed overlay manifests name screens confconsole does not ship: `wireguard.yaml` has `screen: /usr/lib/confconsole/plugins.d/Networking/wireguard.py` (the screen is `Instance/Overlay_network.py`) and `crowdsec.yaml` has `Security/crowdsec.py` (no CrowdSec screen exists). The rules here key on the overlay and the engine, not on that path. ## Test plan - [x] `set -o pipefail; coverage run --branch -m pytest tests`: 789 passed, 7 skipped; 100 percent lines and branches over the measured package, which gains `keelfit` and `keelmenu`; with keel's library on the path 796 passed (the real-resolution tests run) - [x] confconsole 2.2.3+keel12 built and installed with dpkg on the step 8 Keel Web and Keel Core images in LXC on the test VM; `keelmenu.machine()` resolves web (core, web) and core with no data engine; `keelfirstboot.py cloud` skips with and without `_TURNKEY_INIT` - [x] Every Keel menu and screen captured at 80x24 and 100x30: Advanced Menu, Instance (Web and Core, no Database mode), Advanced, Overlay network with no address and with two peers, Address, Add peer, Remove peer, Apply/Export/Show drift/View spec, Core in `cloud_simple` (Overlay in the menu), Keel Cloud with the flag on, and run by name with it off - [ ] Database mode screens on a MariaDB or WordPress image built with manifests (none of the step 8 images carries a database) ## Review follow-ups (9d80eda, 1f96eb9) - `/etc/keel/cloud-endpoint` must hold one `https` URL with a host (bracketed IPv6 allowed), in a root-owned regular file not writable by group or others; anything else keeps Keel Cloud hidden and is logged. Format in docs/Instance.rst. - `keelfit` never passes dialog a size of 0 (tested at 8 columns). - Database mode also shows where the description declares `database.server`, and for Redis: the engines are one set, `keelmenu.DATA_ENGINES = {"mariadb", "postgresql", "redis"}`. - **Gap, not faked:** keel validates `primary`/`replica` for Redis (and PostgreSQL) but `keel spec apply` converges MariaDB only (`system/database.py` returns a note for any other engine), and keel-redis's boot test expects `standalone` only. So Redis gets Database mode > Standalone, no Cloud submenu, and the first boot asks it no role. PostgreSQL loses the Cloud submenu for the same reason. Adding an engine to `REPLICATING_ENGINES` turns it on once keel applies it.