0 Fork 0

Files

T

jakman85andClaude Opus 4.8 d835a27875 fix(plex): mount config PVC at /config (image's real config dir)

The plexinc/pms-docker image writes its identity/claim token and the
Library metadata DB under /config, but the config PVC was mounted at the
renderer default /data/config. Plex therefore wrote all state to the
container's EPHEMERAL layer: the server stayed UNCLAIMED (servers.plex.tv
returns 401 with an empty X-Plex-Token) and lost everything on restart,
which is why seerr's "add Plex" failed even with SSL off.

Set the config volume mountPath to /config in catalog/plex.yaml and
re-render apps/wave-0/plex.yaml (only the mountPath line changes; all
other services byte-identical). No fsGroup/securityContext needed:
verified in-cluster the image inits as root (s6-svscan PID 1), chowns
/config to the plex user, then drops privileges (the "Plex Media Server"
process runs as plex) — root can chown the mounted PVC regardless of
fsGroup.

PLEX_CLAIM auto-claim is intentionally NOT wired: the env secretKeyRef
schema has no `optional`, so a placeholder/absent claim Secret would
crashloop the pod. The claim is an operator step (UI sign-in after the
roll, or add a PLEX_CLAIM env from a fresh https://plex.tv/claim token).

Co-Authored-By: Claude Opus 4.8 <[email protected]>

2026-08-27 18:53:46 -05:00

vms

docs: reconcile the documentation with the deployed reality

2026-08-27 00:00:05 -05:00

wave-0

fix(plex): mount config PVC at /config (image's real config dir)

2026-08-27 18:53:46 -05:00

wave-1

fix(oidc): make gitea + nextcloud OIDC login-source registration persist

2026-08-27 17:41:54 -05:00

wave-2

fix(seerr): add fsGroup podSecurityContext to resolve non-root PVC CrashLoop

2026-08-27 16:58:17 -05:00

README.md

refactor(apps): split monolithic apps Kustomization into dependency waves

2026-08-26 12:19:00 -05:00

README.md

apps

App-tier manifests, rendered from catalog/*.yaml ServiceDefinitions by catalog/render.py and split into dependency-ordered waves (wave-<N>/).

Each wave-<N>/ is reconciled by its own Flux Kustomization apps-wave-<N> (clusters/base/apps-wave-<N>.yaml), which dependsOn wave N-1 (wave 0 dependsOn platform-config) and health-gates (wait: true) ONLY that wave. A crashlooping workload in a later wave can no longer stall an earlier wave or block new revisions.
wave-<N>/kustomization.yaml and clusters/base/apps-wave-<N>.yaml are generated — run python3 catalog/render.py --emit-waves after onboarding a service; do not hand-edit them.
Wave assignment = longest dependency-path depth over the catalog dependencies: graph; a co-located CNPG database <svc>-db is a leaf and always lands strictly below its consumer.

See ../DESIGN-waves.md for the wave table, Flux topology, and the cutover runbook.