Files
jasonwittyandClaude Opus 5 91d96eb17a
Validate and Deploy to K3s / validate (push) Failing after 23s
Validate and Deploy to K3s / deploy (push) Skipped
Add limesurvey, migrating its data off local-path onto GlusterFS
LimeSurvey was never in this repo, and its two PVCs used the k3s local-path
StorageClass: both volumes were pinned to rpi-worker-3's local disk with
persistentVolumeReclaimPolicy: Delete. That put the survey data on a single
SD-backed node with no replication, where deleting the PVC would destroy it.

Both volumes now live on gvolume0 under /mnt/gvolume0/limesurvey/{app,db},
with Retain, matching the pattern used by vaultwarden and tududi. Migrated
2026-09-21 via mysqldump/restore; verified identical afterwards (3 surveys,
742 responses, 2 users, 17 questions, 60 tables).

db-config.yaml is required, not optional: InnoDB's defaults assume a local
POSIX filesystem, and on a GlusterFS FUSE mount native AIO is unavailable and
O_DIRECT unreliable. Without innodb_use_native_aio=0 and
innodb_flush_method=fsync, MariaDB either fails to start or risks corruption.

A nightly dump to /mnt/gvolume0/limesurvey/backups (14 day retention) is
included -- a volume survives losing a node, but a logical dump also survives
corruption, a bad upgrade and mistaken deletes.

The old local-path PVCs (limesurvey-db-data, limesurvey-uploads) are
deliberately left in place as a rollback and are not managed here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-20 19:54:29 -07:00

95 lines
2.1 KiB
YAML

# LimeSurvey was originally deployed with the k3s `local-path` StorageClass,
# which pinned both volumes to rpi-worker-3's local disk with
# persistentVolumeReclaimPolicy: Delete. That meant the survey data lived on a
# single SD-backed node and would be destroyed by deleting the PVC. Migrated to
# GlusterFS 2026-09-21.
#
# Two separate PVCs are correct here because the app and the database run in
# SEPARATE pods. (The warning in apps/tududi/storage.yaml is about declaring the
# same PVC twice as two volume entries in ONE pod -- that is what wedged an
# earlier limesurvey attempt. The app pod below still uses ONE volume, mounted
# twice with subPath.)
apiVersion: v1
kind: PersistentVolume
metadata:
name: limesurvey-pv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
volumeMode: Filesystem
hostPath:
path: /mnt/gvolume0/limesurvey/app
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: limesurvey-app
namespace: limesurvey
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: ""
volumeName: limesurvey-pv
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: limesurvey-db-pv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
volumeMode: Filesystem
hostPath:
path: /mnt/gvolume0/limesurvey/db
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: limesurvey-db
namespace: limesurvey
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: ""
volumeName: limesurvey-db-pv
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: limesurvey-backups-pv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
volumeMode: Filesystem
hostPath:
path: /mnt/gvolume0/limesurvey/backups
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: limesurvey-backups
namespace: limesurvey
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: ""
volumeName: limesurvey-backups-pv