fix/up csi-s3 on ovh-dev to fix github-backups

[devthejo]

Sur le cluster ovh-dev, le job github-backup fail à cause de l'erreur suivante:
[Errno 107] Socket not connected: '/data/repositories'

solution possible:
mettre à jour la csi-s3 yandex

[octomir]

#477

[LucasBassoOcto]

csi a jour lundi 27 Novembre

[LucasBassoOcto]

Investiguer les solutions alternatives possibles

[achauve]

J'ai refait des tests sur les block storages d'ovh, en testant toutes les csi (classic, high speed et high speed gen2).
Le code est ici : https://gist.github.com/achauve/263354b578af43c0c3f76acc16f84f8b

A chaque fois on a bien une erreur :

• un des pods arrive à démarrer normalement
• le deuxième pod a une erreur Attach volume failed

Autre inconvénient (comme pour buildkit-service), il faut un initContainer qui tourne en root pour faire le chmod de départ.

[igorrenquin]

mes notes suite à mon point avec @achauve

Probléme

Pas possible d'attache un volume à 2 POD

On s'apperçoit que la connexion du bucket S3 casse.

Qui est impacté

• 1er cas d'usage, Toutes les applis qui ont besoins d'uploader des fichiers
• 2 ème cas d'usage : backup @achauve -> OK on peut trouver une solution de contournement facilement

Produits impactés cas d'usage 1 :

• carnets
• CDTN-Admin
• DOMIFA
• Tumeplay
• Enfants du spectacle
• MDA -> sur le départs
• Nos 1000jours

Pistes de résolution

Sur le court terme :

option 1 : test csi.s3

• https://github.com/ctrox/csi-s3
• proposition enix : https://github.com/s3fs-fuse/s3fs-fuse
• voir si d'autres existent

option 2 : NAS OVH ou cloud disk array disponible dans les offres baremetal

• demande de devis en cours @igorrenquin

option 3 :

• beta file share OVH
• rook.io -> On évite

Sur le moyen terme :

• évaluer la charge de transformation des produits pour passer de FileShare à S3

Sur les nouveaux produits : utiliser S3 pour stocker les fichiers

[igorrenquin]

L'option retenue c'est la NAS OVH

Attente de BDC pour provisionner le service.

[octomir]

Apres investigation la composante du csi-s3 qui posait problème a été identifié.
il s'agit de Geesefs qui est comme s3fs et rclone responsable de la synchronisation et copie des fichiers vers le S3 disatant
le problème observé avec geesefs, est que la socket unix csi.sock est killed apres quelque minutes ce qui genere un fail kube relance donc la création du pod.
un test abouti avec rclone au lieu de geesefs a permi l'execution complete du pod de backup github sur l'environnement de prod
ns/job => githubbackup/githubèbackup-manual a pour statut completed
une 2e job de backup est en cours d'execution

[matmut7]

Nouveau test : lancer un job qui attend quelques heures et voir si le volume reste monté

[igorrenquin]

• commande NAS OVH

[igorrenquin]

La mise à jour et le paramétrage d'Amir rendent le composant opérationnel et donc une option pour la suite