Skip to content

feat: architecture page with the three scenarios - #4

Merged
marcos-mendez merged 2 commits into
mainfrom
feat/architecture-page
Sep 29, 2026
Merged

marcos-mendez merged 2 commits into
mainfrom
feat/architecture-page

Conversation

@marcos-mendez

@marcos-mendez marcos-mendez commented Sep 29, 2026 •

Copy link
Copy Markdown
Contributor

What the page shows

A new page, architecture.html (served by GitHub Pages at keellinux.org/architecture): the architecture the project aims for, in three scenarios, one inline SVG infographic each, with a status badge in the heading and inside the diagram.

  1. Keel Linux Standalone, "Our goal · not yet released". The goal of the first release: one LXC or VM with application, database and files; keel inspect, keel diff, keel spec apply. It runs from source and test images; there is no release for end users. The network change with its 120 s confirmation window is marked "VM only · in keel 0.9.0, not yet released": in an LXC container the host owns the network and keel only compares it. Webmin shows the network read-only (0019).
  2. Keel Cloud, three nodes, "Planned, decision 0020". Decided, not built. One primary and replicas on WireGuard, two or three of the nodes holding the application; one etcd election by keel-quorum, every data node a voter, the third optionally a data-less voter that is not an appliance; fencing to read-only; database replication and replicas pulling files with rsync. keel-cloud (DNS with a health check, discovery, key exchange) is optional: hand-configured nodes elect and fail over alike, and the public name is then moved by hand. Failover, rejoin and failback choices with 0020's defaults, made once when the set is formed and stored in etcd. The read-only confconsole status panel, and what the design does not promise.
  3. Separated tiers, "Future". A direction with no design yet: only the remote database (0013 phase 1) and Galera (0013 phase 4) are planned pieces. Sharding shown as possible with 0013's caveat.

Example addresses are IPv6 in 2001:db8::/32.

Decisions followed

0013, 0018, 0019, 0020 (final text), and BRIEF section 2 and problem 7.

Other changes

  • An "Architecture" item in the menu of index.html and guidelines.html, and in the footers. Links use architecture.html like guidelines.html, because tools/sitecheck.py resolves links to files; GitHub Pages also serves it at /architecture.
  • index.html Status: the stale "nothing is published" line now says what is served for testing and that there is no release for end users; "What is next" no longer lists inspect, diff and apply as future.
  • README.md lists the new page.
  • style.css: badges, diagram classes on the existing theme variables, the choices table. No new dependency.

Open question

index.html loads the Plausible analytics script; guidelines.html and the new page do not. Left as is, matching guidelines.html: should the script be on every page?

How it was verified

  • python3 tools/sitecheck.py .: 3 pages, 7 assets, 0 findings.
  • The CI command (coverage run -m pytest -q tests, threshold 95): 38 passed, 99 percent.
  • Headless Chromium screenshots at 1280 px and 375 px, light and dark, checked by eye. Each diagram has a wide and a vertical narrow variant, switched at 56rem; the smallest SVG text is 13 px in the viewBox.
  • A clean clone of the pushed branch passes the same checks and renders the page.

A page at /architecture showing how far the Keel Linux architecture goes,
one inline SVG infographic per scenario, each with its status:

- Standalone, available today: one LXC or VM with the whole stack, managed
  with keel inspect, keel diff and keel spec apply. The network change with
  its 120 second confirmation window (decision 0018) is marked as being
  released in keel 0.9.0.
- Keel Cloud with three nodes, planned (decision 0020): one primary and two
  replicas on WireGuard, one etcd election by keel-quorum with fencing,
  replicas pulling files with rsync, keel-cloud optional, the operator's
  failover, rejoin and failback choices, and what the design does not
  promise.
- Separated tiers, future: three application VMs, three database VMs with
  replication or Galera, the remote database of 0013 phase 1, and sharding
  as possible with 0013's caveat.

Each diagram has a wide and a narrow variant, switched at 56rem, so the
text stays legible at phone width. Colours come from the stylesheet's
theme variables, so both themes work. The menu and the footer of every
page gain an Architecture link.
From the review of the first version:

- Scenario 1 is the project's goal, badged "Our goal, not yet released",
  with a sentence saying it runs from source and test images and has no
  release for end users. The page lead says the page shows the
  architecture the project aims for; no "Available today" remains.
- The network converge is VM only: in an LXC container the host owns the
  network and keel only compares it. The tag reads "VM only, in keel
  0.9.0, not yet released".
- Webmin fact reworded after decision 0019. The application examples are
  WordPress, NodeBB and LAMP; there is no Odoo appliance.
- Scenario 2: without Keel Cloud the public name is moved by hand after a
  failover; DNS delay mentions resolvers that ignore low TTLs; two or
  three of the three nodes hold the application.
- Scenario 3 is marked not designed yet: only the remote database (0013
  phase 1) and Galera (0013 phase 4) are planned, and the etcd labels on
  the application tier are gone.
- SVG caption and small text raised to 13 px so it stays legible at phone
  width; the small inline badge may wrap.
- index.html status no longer says nothing is served, and "What is next"
  no longer lists inspect, diff and apply as future. README lists the new
  page.
@marcos-mendez
marcos-mendez merged commit c66474f into main Sep 29, 2026
1 check passed
@marcos-mendez
marcos-mendez deleted the feat/architecture-page branch September 29, 2026 20:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant