[Feature Request]: Dynamic Configuration UI & Admin API (store config in database after db init)

[crivetimihai]

🧭 Epic — Dynamic Configuration UI & Admin API

Field	Value
Title	Add “Configuration” Tab & Admin API for Dynamic Settings
Goal	Let platform admins view, edit, and audit runtime-config parameters from the UI or REST API. Database-stored values override .env at startup and at runtime (hot-reload), eliminating redeploys for most tweaks.
Why now	Growing multi-tenant & LDAP features require faster iteration on limits, feature flags, and branding strings. Manual .env edits + redeploys slow SREs and risk config drift across nodes.
Depends on	Configuration Validation & Schema Enforcement epic (validators), RBAC Multi-Tenancy (admin roles).

On first start, this will use .env. After that, it will copy those settings to the database, and allow you to override them from /admin UI / APIs. Not all settings will be exposed. - for example, security settings are only available through the env.

---

🧭 Type of Feature

• Admin UX
• Reliability / DevOps
• Security (audit trail)

---

🙋‍♂️ User Stories

#	Persona & Need	Key Acceptance Criteria
1	Platform admin — “See all current settings in one place.”	UI tab lists key, effective value, source (env, db, default) & last-change timestamp.
2	Platform admin — “Edit a setting live.”	In UI, change MAX_CONCURRENT_JOBS from 10 → 20; cluster watchers propagate new value within 30 s; running jobs respect limit.
3	DevOps engineer — “Script edits via API.”	PUT /admin/config with JSON payload updates value; responds 200 with new revision ID.
4	Security auditor — “Track who changed what.”	Each change inserts a row in config_audit with user_id, old→new diff, timestamp.

---

📐 Design Sketch

flowchart TD
    UI[Admin UI Config Tab] -->|GET/PUT| ADMINAPI[/admin/config admin JWT/]
    CI[CLI or CI job] -->|REST| ADMINAPI
    ADMINAPI --> CONFIGSV[ConfigService]
    CONFIGSV --> DB[(configuration table)]
    DB -->|NOTIFY| RELOAD[Reload Daemon]
    RELOAD --> CACHE[in-mem cache]
    CACHE --> APP[App Logic]

    classDef db fill:#ffd1dc
    class DB db

Loading

---

🔄 Roll-out Plan

Phase	Feature Flag	Deliverable
0	–	DB migration: configuration & config_audit tables; seed with current .env.
1	EXPERIMENTAL_CONFIG_API	CRUD endpoints behind admin scope; no UI yet.
2	EXPERIMENTAL_CONFIG_UI	React “Configuration” tab (read-only).
3	on (full)	Enable edit-mode, pg LISTEN/NOTIFY hot-reload, audit log.

---

🔧 Task Breakdown

1. Schema & Seed

   • configuration (key PK, value TEXT, type ENUM, source ENUM, updated_at).
   • config_audit (id, key, old, new, user_id, ts).
   • Migration script that imports _env vars as source='env'.

2. Service Layer

   • ConfigService.get(key), .set(key, value, user), .all().
   • JSONSchema per key (leverages Validation epic).
   • Upsert triggers NOTIFY config_changed.

3. Hot-Reload Daemon

   • BackgroundTask subscribes to config_changed; updates in-mem cache.
   • Fallback: full refresh every 5 min.

4. Admin API

   • GET /admin/config (list, filter by source or prefix).
   • PUT /admin/config/{key} (body: {value}) → returns new revision.
   • RBAC: only platform_admin group.

5. Admin UI (React)

   • New sidebar tab “Configuration”.
   • Table with search, inline edit + JSON/YAML modal for complex types.
   • Badge colour ⇒ source (env = grey, db = green).
   • Toast & websocket push when someone else edits a value.

6. CLI Tooling

   • mcpctl config list | get | set KEY VALUE.
   • Baked into CI deploy job to bump feature flags.

7. Validation & Audit

   • Re-use existing Pydantic validators; reject bad type / range.
   • config_audit endpoint & UI timeline component.

8. Docs & Run-books

   • “Making a setting dynamic” guide (add to schema, seed default).
   • Incident SOP: “How to roll back via audit diff.”

9. Tests

   • Unit: set → get round-trip, wrong type → 422.
   • Integration: two nodes; edit on node A, see updated value on node B in ≤30 s.

---

🔄 Alternatives Considered

Option	Pros	Cons	Decision
Keep .env + redeploy only	Simple	5–10 min downtime, config drift	❌
Store in Consul/Etcd	Great for distributed config	New infra dependency	❌
Use HashiCorp Vault for all config	Secrets + config in one	Heavier ACL setup; UI not trivial	🔄 Possibly later

---

📓 Additional Context

• Precedence: DB → ENV → CODE DEFAULT. If a key exists in DB it always wins.
• Safety Net: Certain immutable keys (e.g. JWT_SIGNING_KEY) flagged locked=true; UI blocks edits.
• Observability: config_reload_seconds histogram; alert if reload fails.
• Back-out: Flip feature flag or delete DB row → node falls back to .env.

---

Delivering this epic means: ops can toggle limits, feature flags, banners, and branding instantly from the UI or CI without touching Kubernetes manifests or waiting for redeploys—all with validation, RBAC, and full audit history.