# Prérequis (à faire une seule fois, hors de ce manifeste — même logique que
# deploy/cert-manager/, un composant partagé du cluster, pas par démo) :
#
#   1. Sur CHAQUE nœud du cluster (y compris les workers ARM64 Raspberry Pi —
#      Longhorn supporte officiellement l'ARM64) :
#        apt-get update && apt-get install -y open-iscsi nfs-common
#        systemctl enable --now iscsid
#
#   2. Installer Longhorn (v1.12.0, dernière version stable au moment de
#      l'écriture — vérifier https://github.com/longhorn/longhorn/releases
#      avant d'appliquer une version plus récente) :
#        kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.12.0/deploy/longhorn.yaml
#
#   3. Attendre que tous les pods soient Running avant de déployer une démo :
#        kubectl -n longhorn-system get pods
#
#   4. Appliquer ce manifeste :
#        kubectl apply -f deploy/longhorn/storageclass.yml
#
# Pourquoi : la StorageClass par défaut du cluster (local-path, fournie par
# k3s) attache chaque volume au disque LOCAL du nœud où le pod tourne — si ce
# nœud tombe, le volume devient inaccessible tant qu'il ne redémarre pas,
# avec un vrai risque de perte de données. Cette StorageClass réplique
# chaque volume sur 2 nœuds différents (numberOfReplicas) : si le nœud qui
# héberge le pod tombe, Kubernetes reprogramme le pod ailleurs et Longhorn
# rattache une réplique déjà à jour, sans interruption ni perte.
#
# Utilisée par les PVC postgres/redis/uploads des démos — voir
# deploy/chart-gestion/{postgresql,redis,backend}/values.yaml
# (persistence.storageClass / persistence.uploads.storageClass).
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-replicated
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "2"
  staleReplicaTimeout: "30"
  fsType: "ext4"