| Age | Commit message (Collapse) | Author |
|---|
|
The beets-art CronJob was hard-pinned to r1 via nodeSelector, and its
CPU limit was 2 (half the 4-core passively-cooled Beelink N100 on f1).
The daily noon fetchart/embedart sweep sustained ~35% CPU for ~28 min
and pushed f1 to ~95 C, tripping the FreebsdCpuTemperatureHigh alert
(>=80 C for 5m).
Two changes:
1. Cap the container CPU limit from 2 to 1. The run takes ~2x longer but
stays well under the 6h activeDeadlineSeconds and roughly halves the
sustained thermal load.
2. Unpin the CronJob from r1 so the scheduler can spread it. This is a
manifest/config change, not a storage migration: the music library is
already shared NFS (mounted at the same path on all three r-nodes).
The only thing forcing r1 was the music PV/PVC being declared RWO
(single-node mount) while shared with Navidrome, which is itself pinned
to r1 by its local-path SQLite data PVC. Flip navidrome-music PV/PVC
to ReadWriteMany so beets-art can mount it on any r-node alongside the
read-only Navidrome pod.
Also move beets-art-state from local-path (pinned to r1) to a static
NFS-backed RWX PV/PVC so the job's SQLite state is reachable from any
node. SQLite-over-NFS is acceptable here because concurrencyPolicy:
Forbid guarantees a single writer (no lock contention), and the state
is regenerable.
Application requires recreating the bound music PVC (access-mode changes
are immutable on a bound PVC) and the state PVC; see deploy notes.
|
|
|
|
Pinning to a specific version avoids silent breaking upgrades and makes
kubectl rollout undo meaningful. IfNotPresent skips unnecessary re-pulls
on pod restarts.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
|
SQLite over NFS causes two problems: file-lock races on rolling
restarts (fixed with Recreate strategy but underlying fragility
remains), and 19s image-cache init at startup due to stunnel TLS
latency on every cache read.
Replace navidrome-data-pv/pvc (static hostPath over NFS at
/data/nfs/k3svolumes/navidrome/data) with a dynamic local-path PVC
provisioned on r1 (/var/lib/rancher/k3s/storage). Pin the deployment
to r1 via nodeSelector so the local PV is always reachable.
Existing DB and cache migrated: navidrome.db (23 MB), image/background/
plugin caches (~118 MB) copied via a migration pod before first start.
Result: startupTime=41ms (was ~20s), Image cache init=29ms (was ~19s).
Music PVC stays on NFS (200 GB library, unchanged).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
|
SQLite on RWO PVC can only have one writer. RollingUpdate keeps the old
pod alive until the new pod is Ready, but the new pod blocks
indefinitely on SQLite open because the old pod still holds the
db-shm/db-wal lock. Recreate kills the old pod first.
Amp-Thread-ID: https://ampcode.com/threads/T-019e109f-fa43-7467-bb0b-1a4a2d3d0b9e
Co-authored-by: Amp <amp@ampcode.com>
|
|
Prevents Traefik from routing traffic to navidrome before it has
finished its ~1m14s cold start (NFS cache warm-up + initial scan),
which was causing 501s and 'context canceled' errors right after
each cluster boot.
Amp-Thread-ID: https://ampcode.com/threads/T-019e109f-fa43-7467-bb0b-1a4a2d3d0b9e
Co-authored-by: Amp <amp@ampcode.com>
|
|
|
|
- Add cert-manager for self-signed TLS certificates
- Create wildcard cert for *.f3s.lan.buetow.org
- Add LAN ingress to Navidrome (navidrome.f3s.lan.buetow.org)
- Document FreeBSD relayd configuration for LAN access
- Add comprehensive setup guide
LAN access uses existing CARP VIP (192.168.1.138) on f0/f1
with relayd forwarding HTTP/HTTPS to k3s Traefik NodePorts.
External access via OpenBSD relayd continues unchanged.
|
|
Adds Navidrome music streaming server with:
- Helm chart with deployment, service, ingress, and persistent volumes
- Two PVs: data (10Gi) and music library (200Gi)
- ArgoCD application for automated deployment
- Ingress at navidrome.f3s.buetow.org
- Justfile for operational commands
|
