chore: build

deploy/velero/schedule.yml

@@ -1,36 +1,24 @@
-# Sauvegarde quotidienne de tous les namespaces de démo (postgres, redis,
-# uploads, et le reste : Secrets/ConfigMaps/Deployments pour une
-# restauration complète) vers le bucket S3 configuré dans values.yaml.
-# S'applique par défaut à TOUT namespace non exclu ci-dessous — une nouvelle
-# démo créée dynamiquement (demo-xxxxx, premium-xxxxx) est donc couverte
-# automatiquement, sans modifier ce fichier.
+# Il n'y a plus de Schedule Velero statique/global ici (l'ancienne version de
+# ce fichier en définissait deux : demos-daily et demos-frequent, couvrant
+# TOUS les namespaces en un seul objet Backup par exécution).
 #
-# À appliquer après l'installation de Velero (voir values.yaml) :
-#   kubectl apply -f deploy/velero/schedule.yml
-apiVersion: velero.io/v1
-kind: Schedule
-metadata:
-  name: demos-daily
-  namespace: velero
-spec:
-  # 03h00 UTC, tous les jours — heure creuse pour ce cluster.
-  schedule: "0 3 * * *"
-  template:
-    includedNamespaces:
-      - "*"
-    excludedNamespaces:
-      - kube-system
-      - kube-public
-      - kube-node-lease
-      - default
-      - velero
-      - traefik
-      - longhorn-system
-      - cert-manager
-    # Sauvegarde le contenu réel des PVC (postgres/redis/uploads) via
-    # File System Backup — voir values.yaml.
-    defaultVolumesToFsBackup: true
-    storageLocation: default
-    # Conservation 30 jours : au-delà, la sauvegarde devient éligible à la
-    # purge automatique (garbage collection Velero).
-    ttl: 720h0m0s
+# Pourquoi ce changement : Velero ne permet de supprimer qu'un objet Backup
+# ENTIER, jamais une portion (ex: "juste les données de la démo X"). Avec un
+# planning global multi-namespace, détruire une démo n'aurait donc jamais pu
+# supprimer ses sauvegardes sans supprimer aussi celles des autres démos
+# présentes dans le même Backup.
+#
+# À la place, le control-plane crée maintenant un Schedule Velero DÉDIÉ par
+# démo (voir HelmProvisioner.ensureDemoBackupSchedule dans
+# control-plane/api/internal/demos/helm_provisioner.go) :
+#   - à la création de la démo (Provision) et lors d'un passage en premium
+#     (MigrateToPremiumNamespace, un nouveau namespace = un nouveau planning) ;
+#   - toutes les 15 min, conservées 24h (fenêtre de perte de données
+#     minimale en cas de problème sur le cluster) ;
+#   - supprimé avec ses Backup déjà pris (HelmProvisioner.deleteDemoBackups)
+#     quand la démo est détruite — expiration du TTL ou destruction forcée
+#     par un admin, les deux passent par Service.Delete → Teardown.
+#
+# Rien à appliquer manuellement ici : ces Schedule sont gérés entièrement
+# par le control-plane, dans le namespace "velero", nommés
+# "demo-backup-<namespace>".

deploy/velero/values.yaml

@@ -25,7 +25,8 @@
 #        helm install velero vmware-tanzu/velero \
 #          --namespace velero --version 12.1.0 \
 #          -f deploy/velero/values.yaml
-#        kubectl apply -f deploy/velero/schedule.yml
+#      Rien d'autre à appliquer : les plannings de sauvegarde sont créés
+#      dynamiquement par démo par le control-plane, voir deploy/velero/schedule.yml.
 #
 #   5. Sécurité du bucket — à vérifier CÔTÉ RustFS/MinIO (rien de tout ça ne
 #      se configure depuis ce repo) : chaque sauvegarde contient les Secrets
@@ -68,21 +69,23 @@ configuration:
     - name: default
       provider: aws
       # Nom du bucket créé à l'étape 1. Requis.
-      bucket: "CHANGE_ME_bucket_name"
+      bucket: "backup-omnex"
       default: true
       credential:
         name: cloud-credentials
         key: cloud
       config:
         region: "us-east-1"
-        s3Url: "CHANGE_ME_https://votre-endpoint-rustfs-ou-minio"
+        s3Url: "https://backup-omnex.uber-stup.club"
         s3ForcePathStyle: "true"
         insecureSkipTLSVerify: "false"
-        # Chiffrement côté serveur du contenu des sauvegardes (SSE-S3,
-        # AES256 géré par le bucket) — RustFS et MinIO le supportent tous
-        # les deux. Ne dispense pas de vérifier le chiffrement at-rest réel
-        # du stockage sous-jacent (voir étape 5 ci-dessus).
-        serverSideEncryption: "AES256"
+        # Pas de serverSideEncryption ici : ce RustFS refuse le SSE-S3 tant
+        # que RUSTFS_SSE_S3_MASTER_KEY (clé base64 32 octets) n'est pas
+        # configurée côté serveur ("InvalidRequest: SSE-S3 requires
+        # RUSTFS_SSE_S3_MASTER_KEY..."), réglage hors de portée depuis ce
+        # repo. Le transport reste chiffré (HTTPS) ; pour du chiffrement
+        # at-rest, configurer cette variable côté serveur RustFS puis
+        # remettre serverSideEncryption: "AES256" ici.
 
   volumeSnapshotLocation: []