TELEICU/Decision matrix: Difference between revisions
From OHC Network Wiki
More languages
More actions
Content deleted Content added
Create TELEICU decision matrix reference page (via create-page on MediaWiki MCP Server) |
Automated edit (via update-page on MediaWiki MCP Server) |
||
| 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}} |
||
Latest revision as of 08:39, 6 July 2026
Side-by-side comparison of Path A (Ansible Pull) and Path B (NixOS) across every decision dimension.
Comparison
| 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.