UX Layer for GitOps: Improve operability without sacrificing declarative guarantees #3

New issue

Open

opened 2026-08-05 17:11:31 +02:00 by tdpeuter · 0 comments

tdpeuter commented

2026-08-05 17:11:31 +02:00

Owner

Summary

Our GitOps foundation is strong, but day-to-day operations are still CLI-heavy and fragmented.
We should add a lightweight UX/control layer that improves visibility and common workflows while preserving our pull-based, declarative model.

Problem

Today, operational tasks (status checks, rollout tracking, common edits) require deep repo/system knowledge and manual steps.
This slows routine operations and raises cognitive load.

Goal

Create a UX layer that:

Reads system state clearly (host/service health, deployment status)
Proposes changes through Git commits/PRs
Triggers convergence via existing GitOps pathways (webhook/timer/systemd)

Core Principle

No direct imperative host mutation from UI/API.
If an action cannot be represented as a Git change or explicit orchestrated workflow, it is out of scope.

Scope (v1)

Dashboard for:
- Host status
- Last deployed revision per host
- Service health overview
Deployment timeline:
- commit -> webhook/timer trigger -> host pull -> apply result
“One-click” workflows that open PRs for common tasks:
- bump app versions
- enable/disable known modules
- host-level config toggles
ChatOps-style commands that map to Git actions/workflows (not SSH execution)

Non-goals

Replacing Nix/flake workflows
Direct remote command execution on hosts
Introducing a push-based configuration model

Acceptance Criteria

Operators can see cluster status in one place without SSHing into nodes
At least 3 common changes can be initiated via guided flow and result in PRs
Deployment progress is visible from commit to applied revision
All applied config changes still flow through GitOps pull convergence
No privileged long-lived SSH root channel introduced

Notes

This should preserve the current architecture strengths (declarative, auditable, pull-based) while significantly improving usability and speed of routine operations.

## Summary Our GitOps foundation is strong, but day-to-day operations are still CLI-heavy and fragmented. We should add a lightweight UX/control layer that improves visibility and common workflows while preserving our pull-based, declarative model. ## Problem Today, operational tasks (status checks, rollout tracking, common edits) require deep repo/system knowledge and manual steps. This slows routine operations and raises cognitive load. ## Goal Create a UX layer that: 1. Reads system state clearly (host/service health, deployment status) 2. Proposes changes through Git commits/PRs 3. Triggers convergence via existing GitOps pathways (webhook/timer/systemd) ## Core Principle **No direct imperative host mutation from UI/API.** If an action cannot be represented as a Git change or explicit orchestrated workflow, it is out of scope. ## Scope (v1) - Dashboard for: - Host status - Last deployed revision per host - Service health overview - Deployment timeline: - commit -> webhook/timer trigger -> host pull -> apply result - “One-click” workflows that open PRs for common tasks: - bump app versions - enable/disable known modules - host-level config toggles - ChatOps-style commands that map to Git actions/workflows (not SSH execution) ## Non-goals - Replacing Nix/flake workflows - Direct remote command execution on hosts - Introducing a push-based configuration model ## Acceptance Criteria - [ ] Operators can see cluster status in one place without SSHing into nodes - [ ] At least 3 common changes can be initiated via guided flow and result in PRs - [ ] Deployment progress is visible from commit to applied revision - [ ] All applied config changes still flow through GitOps pull convergence - [ ] No privileged long-lived SSH root channel introduced ## Notes This should preserve the current architecture strengths (declarative, auditable, pull-based) while significantly improving usability and speed of routine operations.