feat: the primary hands out what a replica needs, and the password both ends hold #12

Merged

marcos-mendez merged 3 commits from feat/database-mode-handout into master

2026-09-30 02:49:38 -03:00

marcos-mendez commented

2026-09-30 02:32:48 -03:00

(Migrated from github.com)

What the operator sees now

Cloud / Primary: a loopback-only "Answer on" is prefilled with this node's stable addresses, public IPv6 first. When the password file is empty the screen offers to generate a password (No lets the operator type one). After keel spec apply --system-only, it shows what each replica needs: the addresses to replicate from, IPv6 first, with [addr]:3306, the account keel names (repl), and the file holding the password. It shows the generated password once. A password that already exists is kept and never shown or regenerated.
Cloud / Replica: asks for the primary's address, the port and the addresses to answer on, then the password in a hidden box (blank keeps the file's value). Before anything changes it asks: "Becoming a replica REPLACES the data on this node with a copy of the primary". keel's own refusal naming the databases is still asked separately before --destroy-local-database is passed.
Standalone and Promote are unchanged; every Cloud screen keeps the no-automatic-failover line.

How it calls keel

Unchanged: the screen stages database.server, runs keel spec validate --no-secret-files, commits, then runs keel spec apply --system-only --non-interactive. No SQL in confconsole. The only new side effect is the secret file (0600, directory 0700, one trailing newline, the format keel's read_secret_file expects). It is written after validation and before the commit, so a refused description leaves no credential, and the value never appears in argv. keel refuses generate: true for this secret (both ends must match), which is why the console generates it. No keel change is needed.

Review fixes (`c690db7`)

Apply now passes --skip-network --defer-certificate. "Allow replication from" is prefilled with this node's public /64, and an empty list is flagged in the handout. A failed apply still shows the password, under a not-ready warning. The handout is a textbox read from a private 0700 dir, because msgbox text is dialog argv, readable in /proc. The secret is written atomically, the staged description has a unique name, and a missing description is started fresh. No to the destroy question rolls back the description and the secret, then re-applies the old description. Addresses are shown bare, and pasted brackets are accepted.

Tests

504 pytest (+85, the last 11 from the final verification in 8cdf7ee: a failed commit takes its password back, No is re-applied only when the old description declares a server, the handout survives a terminal too small for it; new tests/test_database_handout.py), 100 percent lines and branches over the measured package. The keel/spec/screen fixtures moved to conftest.py; FakeConsole answers the password box and the textbox.

Proven on VM1 (TurnKey 19, keel 0.10.0)

Two MariaDB 11.8 nodes in overlayfs chroots under /tmp, driven through these screens with scripted answers against the real keel: primary configured and password generated; replica joined over IPv6 after both confirmations (dropping a local wordpress); rows written on the primary read on the replica (Slave_IO/SQL_Running: Yes, Using_Gtid: Slave_Pos); promotion done, with keel diff reporting the role drift. This run found and fixed one defect: the prefill had taken the interface's fd00:: address rather than its public one. Everything was removed afterwards.

Handbook decision 0013 ("What the operator sees", "Several replicas"), toward Keel-Linux/keel-mariadb#9. The Database mode menu from #10 had the right shape, but a MariaDB pair could still only be built from the command line: the primary showed nothing a replica needs, and both ends asked for a password file the operator had to create by hand. ## What the operator sees now - **Cloud / Primary**: a loopback-only "Answer on" is prefilled with this node's stable addresses, public IPv6 first. When the password file is empty the screen offers to generate a password (No lets the operator type one). After `keel spec apply --system-only`, it shows what each replica needs: the addresses to replicate from, IPv6 first, with `[addr]:3306`, the account keel names (`repl`), and the file holding the password. It shows the generated password **once**. A password that already exists is kept and never shown or regenerated. - **Cloud / Replica**: asks for the primary's address, the port and the addresses to answer on, then the password in a hidden box (blank keeps the file's value). Before anything changes it asks: "Becoming a replica REPLACES the data on this node with a copy of the primary". keel's own refusal naming the databases is still asked separately before `--destroy-local-database` is passed. - Standalone and Promote are unchanged; every Cloud screen keeps the no-automatic-failover line. ## How it calls keel Unchanged: the screen stages `database.server`, runs `keel spec validate --no-secret-files`, commits, then runs `keel spec apply --system-only --non-interactive`. No SQL in confconsole. The only new side effect is the secret file (0600, directory 0700, one trailing newline, the format keel's `read_secret_file` expects). It is written after validation and before the commit, so a refused description leaves no credential, and the value never appears in argv. keel refuses `generate: true` for this secret (both ends must match), which is why the console generates it. No keel change is needed. ## Review fixes (c690db7) Apply now passes `--skip-network --defer-certificate`. "Allow replication from" is prefilled with this node's public /64, and an empty list is flagged in the handout. A failed apply still shows the password, under a not-ready warning. The handout is a textbox read from a private 0700 dir, because msgbox text is dialog argv, readable in `/proc`. The secret is written atomically, the staged description has a unique name, and a missing description is started fresh. No to the destroy question rolls back the description and the secret, then re-applies the old description. Addresses are shown bare, and pasted brackets are accepted. ## Tests 504 pytest (+85, the last 11 from the final verification in 8cdf7ee: a failed commit takes its password back, No is re-applied only when the old description declares a server, the handout survives a terminal too small for it; new `tests/test_database_handout.py`), 100 percent lines and branches over the measured package. The `keel`/`spec`/`screen` fixtures moved to `conftest.py`; `FakeConsole` answers the password box and the textbox. ## Proven on VM1 (TurnKey 19, keel 0.10.0) Two MariaDB 11.8 nodes in overlayfs chroots under /tmp, driven through these screens with scripted answers against the real keel: primary configured and password generated; replica joined over IPv6 after both confirmations (dropping a local `wordpress`); rows written on the primary read on the replica (`Slave_IO/SQL_Running: Yes`, `Using_Gtid: Slave_Pos`); promotion done, with `keel diff` reporting the role drift. This run found and fixed one defect: the prefill had taken the interface's `fd00::` address rather than its public one. Everything was removed afterwards.