Repository navigation
ci(qualification): add Ubuntu 24.04 k3s scenario #3455
Description
Activity
- addedos:linuxIssue affects Linux hostsIssue affects Linux hosts
on Sep 18, 2026 - added a parent issue
on Sep 18, 2026 Taking a run at this. Not sure I'm the "right guy" now, but I'm the "right now" guy.
🏗️ build-plan
Implementation Plan
Issue type:
feat
Complexity: High
Confidence: Medium — the Kubernetes installer and disposable cluster lifecycle need integration verificationSummary
Add an Ubuntu 24.04 k3s environment to tmachine. Pin the k3s release, verify cluster readiness and report its effective version and node state. Expose protected guest-local cluster inputs to a separate OpenShell installation profile and the existing conformance testsuite. Keep cluster state on a run-scoped disk and retain redacted diagnostics when a run fails.
Scope
tests/config.nix,tests/ansible/playbooks/: define the k3s scenario and an independent Kubernetes installation profile, with a guest-local kubeconfig contract.tests/tmachine/src/: pass environment values through setup, installation, and tests; avoid caching k3s state; collect bounded diagnostics and clean up on failure or interruption..github/workflows/integration-runner.ymland caller matrices: invoke the k3s composition and upload sanitized failure artifacts.architecture/build.md: describe the scenario, profile, inputs, and local invocation.
Implementation Steps
- Provision a pinned k3s release in an Ubuntu 24.04 guest; wait for the service, API, and node; report version and node state.
- Carry environment-owned cluster values to later tmachine phases. Keep kubeconfig permissions restrictive and cluster state on a disposable disk.
- Add a Kubernetes OpenShell installation profile that consumes candidate artifacts; run the unchanged shared conformance suite against it.
- Capture useful redacted guest, systemd, k3s, Kubernetes, gateway, and sandbox diagnostics on failure, then remove the disposable guest on success, error, and interruption.
- Wire the composition into local tmachine and GitHub Actions, update architecture documentation, and verify.
Test Plan
- Unit tests: tmachine configuration and environment input forwarding; pin/readiness and cleanup logic where testable without a VM.
- Integration tests: run
nix run .#tmachine -- test ubuntu-k3s kubernetes-binaries conformanceand inspect diagnostic artifacts and cleanup. - E2E tests: run the k3s tuple in the integration workflow on a KVM runner, including a failing run and interruption cleanup check.
Risks & Open Questions
- Existing installers only support Docker and Podman, so this issue needs a separate Kubernetes installer profile to satisfy composition. Keep OpenShell behavior out of the k3s scenario itself.
- The current cached setup/install disks would retain cluster credentials; k3s must use a run-scoped disk.
- Local KVM and candidate artifacts may be unavailable; if so, report the exact unverified gate instead of claiming a passing qualification run.
Documentation Impact
- Update
architecture/build.md. Review related contributor skills for workflow drift. No gateway TOML or driver defaults are expected to change.
Revision 1 — initial plan
Implementation is in PR #3651. It adds a pinned Ubuntu 24.04 k3s tmachine environment, a Kubernetes binary/image installer, the shared conformance testsuite in the branch E2E matrix, disposable VM lifecycle, and redacted failure diagnostics. Local
mise run pre-commit,mise run test,mise run ci, tmachine unit tests, and Ansible syntax checks passed. The PR hastest:e2eand the branch E2E run has been rerun to validate the guest scenario.Verification update: PR #3651 now has a passing Ubuntu 24.04 k3s conformance job in the Branch E2E workflow (run 35937628601). All 93 PR checks are passing.
- addedstate:pr-openedPR has been opened for this issuePR has been opened for this issueand removed
on Sep 24, 2026
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
Description
Add an Ubuntu 24.04 k3s scenario for Kubernetes release qualification. The scenario provisions a disposable Ubuntu guest and a pinned k3s version, then exposes the cluster inputs needed by independently selected OpenShell installation profiles and testsuites.
The scenario owns guest and cluster setup only. It must not embed OpenShell installation or conformance behavior.
Context
This follows the initial Docker and Podman proof of concept and extends the same qualification composition model to a local Kubernetes environment.
Definition of Done
tmachineand from GitHub Actions.