Roadmap: Keel Linux composition architecture (0023-0040) #46
Labels
No labels
accessibility
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Keel-Linux/tracker#46
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Roadmap for the composition architecture decided by the maintainer on 2026-09-30, recorded as handbook notes 0023 to 0040 (handbook#26). One layer at a time; every phase ships something testable, and a phase is done only when its criterion holds on a built image, not on a hand-assembled machine.
Decision issues: #28 (0023) #29 (0024) #30 (0025) #31 (0026) #32 (0027) #33 (0028) #34 (0029) #35 (0030) #36 (0031) #37 (0032) #38 (0033) #39 (0034) #40 (0035) #41 (0036) #42 (0037) #43 (0038) #44 (0039) #45 (0040)
Phase 0: sharpen the axe
Done when: the manifest schema is reviewed with WordPress, Odoo and Mastodon examples, Template B4 passes the maintainer's test, and no published layer carries a shared key.
Phase 1: Keel Core
Decisions: #29 #30 #32 #33 #34 #41 #44
Done when: a Core image boots in simple installation, emits a YAML that re-applies as a no-op, runs no etcd and no active CrowdSec, and upgrades one overlay with
apt upgradeon the testing track.Phase 2: data appliances, standalone and paired
Decisions: #36 #38 #33
Done when: each engine passes a two-container gate in cloud simple: write on the primary, read on the standby, commit latency and the synchronous or semi-synchronous fallback measured, promotion by hand.
Phase 3: Keel Web
Decisions: #35 #34
Done when: Keel Web in advanced mode blocks a CRS test payload, challenges a browser through Anubis, lets exempt crawlers through, and in simple mode is plain Nginx.
Phase 4: runtimes, and WordPress on Keel PHP
Decisions: #28 #39 #41
Done when: WordPress on Keel PHP passes the appliance gate in simple and cloud simple, built from its manifest, with no Apache in the image.
Phase 5: mesh control plane
Decisions: #29 #30 #31 #33 #34 #37 #45
Done when: a three-container gate installs the second and third node by discovery, fails over automatically, moves the VIP, flips the Syncthing folders, fails back after catch-up, and reports each node's Monit summary through etcd.
Phase 6: applications by manifest
Decisions: #39 #40 #38
Done when: each passes the gate in simple and cloud advanced from its manifest alone plus its inithook, Mastodon last.
Phase 7: object storage and backup
Decisions: #43 #42
s3overlay with zones from the site label (#43)Done when: an application is backed up from its standby to Keel Backup in another site, and a scheduled restore test succeeds and is visible in etcd.
Open architecture items
Decisions of 2026-10-02 (handbook#38): #49 (0044, Keel Web in the cloud) and #50 (0045, Keel DNS, PowerDNS authoritative). They go after Phase 3 (Keel Web) and before Phase 5 (mesh control plane): Keel DNS is built as a standalone appliance without etcd, and its registry feed comes in Phase 5.
Between Phase 3 and Phase 5: Keel DNS, and Keel Web in the cloud
Decisions: #49 #50
keel-overlay-pdns(PowerDNS 4.9.17 from trixie,gsqlite3, LUA records on) and thekeel-dnsappliance on Core, simple mode (#50)websection shared across a set, certificates as shared secrets (#49)Done when: two Keel DNS servers in two sites answer for a test zone with only the live Keel Web nodes, a stopped node leaves the answers within a check interval plus the TTL, and a second Keel Web node serves the same sites and certificates as the first.
Added to Phase 5: the Keel DNS feed from the etcd registry, cloud advanced on three sites (#50), and the
websection through etcd (#49).The open architecture item "DNS successor for nodes behind NAT with changing IPv6 prefixes" is decided by 0045 (#50).
Phase 4 (Keel PHP plus WordPress) is based on decision 0047, one image per application: one debian-13-keel-wordpress image on Core, Web and PHP with an embedded MariaDB, the installation mode deciding what runs. Keel-Linux/handbook#40.
Deferred to after the main applications work (maintainer, 2026-10-02): MongoDB and CouchDB data appliances. TurnKey ships both (turnkeylinux-apps/mongodb, couchdb). Neither is in Debian 13: MongoDB is SSPL-licensed (not OSI-approved, would need MongoDB's own repository, against 0039), CouchDB is Apache 2.0 but would need a Keel package. Revisit after Phase 6 (applications by manifest), case by case on demand; CouchDB is the cleaner path. The data services in scope now stay those of 0033: PostgreSQL, MariaDB, Redis, and search (Elasticsearch or OpenSearch). Redis is being added to confconsole's Database mode (confconsole#19).