Admin: Automated edit (via update-page on MediaWiki MCP Server)

2026-07-06T03:09:42Z

Automated edit (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 08:39, 6 July 2026
Line 89:		Line 89:
	* '''Choose Path A (Ansible Pull) if:''' the team already knows Ansible, you cannot repartition disks, and soft drift guarantees are acceptable.		* '''Choose Path A (Ansible Pull) if:''' the team already knows Ansible, you cannot repartition disks, and soft drift guarantees are acceptable.
	* '''Choose Path B (NixOS) if:''' tampering is the #1 problem, you want full immutability, and the team can invest in learning Nix.		* '''Choose Path B (NixOS) if:''' tampering is the #1 problem, you want full immutability, and the team can invest in learning Nix.

			{{Navbox TELEICU}}

	{{Related}}		{{Related}}

Admin: Create TELEICU decision matrix reference page (via create-page on MediaWiki MCP Server)

2026-07-06T02:52:56Z

Create TELEICU decision matrix reference page (via create-page on MediaWiki MCP Server)

New page

{{Doc header
|type=reference
|domain=teleicu
|title=Decision matrix
|order=6
}}

Side-by-side comparison of Path A (Ansible Pull) and Path B (NixOS) across every decision dimension.

== Comparison ==

{| class="wikitable"
|-
! Dimension
! Path A: Ansible Pull
! Path B: NixOS
! Notes
|-
| OS
| Ubuntu 20.04/22.04/24.04 (kept in-place)
| NixOS (fresh install via nixos-anywhere)
| Path A works with existing OS; B reformats
|-
| Immutability
| Soft — ansible-pull reconciles on check-in
| Hard — /etc is read-only, tamper-proof at OS level
| B eliminates tampering; A reduces it
|-
| Storage
| Longhorn on existing partitions
| ZFS + OpenEBS localPV
| A cannot repartition; B redoes disks entirely
|-
| Provisioning
| Manual/netboot minimal OS → ansible-pull
| Custom ISO with pre-configured tunnel → nixos-anywhere
| B's ISO is zero-touch; A requires bootstrap step
|-
| Update mechanism
| ansible-pull (git-based, cron/timer)
| comin (pull, primary) / deploy-rs (push, backup)
| Both pull-based; B has fallback push path
|-
| Config language
| YAML (Ansible)
| Nix
| Ansible: widely known. Nix: steep learning curve
|-
| Secrets
| Ansible Vault + sops
| sops-nix
| Both use sops; different integration points
|-
| Rollback
| git revert + ansible-pull re-runs
| nixos-rebuild switch --rollback or select boot generation
| NixOS rollback is instant, generation-based
|-
| Disk repartitioning
| Not possible — existing partitions stay
| Full ZFS layout via disko
| Major constraint for Path A
|-
| Existing hardware
| Works as-is
| May need UEFI/boot-mode changes
| Check hardware compatibility for B
|-
| Team readiness
| Low barrier — existing ops skills transfer
| High barrier — need Nix onboarding
| Consider ramp-up time
|-
| Offline operation
| ansible-pull fails gracefully, retries on reconnect
| comin polls, applies pending generation on reconnect
| Both handle offline; B has clearer state model
|-
| Audit trail
| Git log of ansible-pull repo
| Nix store history + generation timeline
| B provides bit-level provenance
|}

== Recommendation framework ==

Neither path is universally better. Consider:

* '''Choose Path A (Ansible Pull) if:''' the team already knows Ansible, you cannot repartition disks, and soft drift guarantees are acceptable.
* '''Choose Path B (NixOS) if:''' tampering is the #1 problem, you want full immutability, and the team can invest in learning Nix.

{{Related}}

TELEICU/Decision matrix - Revision history

Admin: Automated edit (via update-page on MediaWiki MCP Server)

Admin: Create TELEICU decision matrix reference page (via create-page on MediaWiki MCP Server)