The Instance menu offers a database mode, this node only #10

Merged

marcos-mendez merged 1 commit from feat/instance-database-mode into master

2026-09-27 14:44:27 -03:00

marcos-mendez commented

2026-09-27 10:20:15 -03:00

(Migrated from github.com)

The console half of handbook decision 0013, and the console part of
keel-mariadb#9.

Instance
  Database mode
    Standalone                 one server, replicating nothing
    Cloud
      Primary                  other nodes may replicate from this one
      Replica                  this node replicates from another
      Promote this replica     an explicit act, with its own question

What the screens are

Each configures the machine it runs on. Primary asks for the addresses this
node answers on, the origins it allows to replicate from it and the file
holding the replication credential; it creates no replica anywhere. Replica
asks for the primary's literal IPv6 address, the port, the addresses and the
same credential file.

The screens hold no decision of their own. dbscreen collects the fields,
writes them into /etc/keel/instance.yaml and hands it to keel; what a role
means, and every refusal, is keel's (keel#30). So the console and the headless
run are one code path, which is the rule of brief section 6.

The three things they must say, and do

No automatic failover, in a line on every cloud screen. Promotion is
something the operator does, on the replica, from this menu.
Becoming a replica replaces the local database. The console never
decides that: keel refuses, the screen repeats keel's own refusal and
asks, and only a Yes adds --destroy-local-database. No other screen
offers it.
Promoting while the old primary runs leaves two writable servers holding
one dataset. The promotion question says so before it asks.

What the operator typed is staged beside the description and given to keel spec validate before it replaces it, so a value that would not load cannot
replace one that does. The engine is never asked of the operator: it comes
from the description, or from keel inspect when the description has none.

Needs keel#30 for --destroy-local-database and keel#31 for
keel database promote. Without them the screens show keel's usage error
rather than doing something else, which is the same one code path rule.

Test plan

tests/test_database_mode.py: 63 tests. What each role builds, staging and
committing and discarding, the refusal read out of what apply printed, the
order stage / validate / commit / apply and every way each step can fail,
the four screens loaded the way confconsole loads them, and the one
question whose Yes loses data.
tests/test_instance_menu.py: the menu holds the four spec entries and the
four screens, each submenu describes itself, and the modes come in the
order decision 0013 settled.
Coverage 100 percent over 379 tests, threshold 100, measured
package now ifutil,keelbanner,keelcli,dbscreen,plugins.d/Instance.

The console half of handbook decision 0013, and the console part of keel-mariadb#9. ``` Instance Database mode Standalone one server, replicating nothing Cloud Primary other nodes may replicate from this one Replica this node replicates from another Promote this replica an explicit act, with its own question ``` ## What the screens are Each configures the machine it runs on. Primary asks for the addresses this node answers on, the origins it allows to replicate from it and the file holding the replication credential; it creates no replica anywhere. Replica asks for the primary's literal IPv6 address, the port, the addresses and the same credential file. The screens hold no decision of their own. `dbscreen` collects the fields, writes them into `/etc/keel/instance.yaml` and hands it to `keel`; what a role means, and every refusal, is keel's (keel#30). So the console and the headless run are one code path, which is the rule of brief section 6. ## The three things they must say, and do - **No automatic failover**, in a line on every cloud screen. Promotion is something the operator does, on the replica, from this menu. - **Becoming a replica replaces the local database.** The console never decides that: keel refuses, the screen repeats *keel's own refusal* and asks, and only a Yes adds `--destroy-local-database`. No other screen offers it. - **Promoting while the old primary runs leaves two writable servers holding one dataset.** The promotion question says so before it asks. What the operator typed is staged beside the description and given to `keel spec validate` before it replaces it, so a value that would not load cannot replace one that does. The engine is never asked of the operator: it comes from the description, or from `keel inspect` when the description has none. Needs keel#30 for `--destroy-local-database` and keel#31 for `keel database promote`. Without them the screens show keel's usage error rather than doing something else, which is the same one code path rule. ## Test plan - `tests/test_database_mode.py`: 63 tests. What each role builds, staging and committing and discarding, the refusal read out of what apply printed, the order stage / validate / commit / apply and every way each step can fail, the four screens loaded the way confconsole loads them, and the one question whose Yes loses data. - `tests/test_instance_menu.py`: the menu holds the four spec entries and the four screens, each submenu describes itself, and the modes come in the order decision 0013 settled. - Coverage **100 percent** over **379 tests**, threshold 100, measured package now `ifutil,keelbanner,keelcli,dbscreen,plugins.d/Instance`.