Gestion espace de stockage (archivage)

[svergeylen]

Suppression / archivage du passé à méditer

• getsion de l'espace disque à vérifier / monitorer (c'est pas que 10Go un VM ovh ?? c'est peu !)

[dvergeylen]

Coucou,

Ça me gêne aussi un peu que les images soient stockées en direct sur le serveur, il doit y avoir moyen de faire mieux.

Deux propositions d'idées:

• [ ] Paperclip est maintenant deprecated (!), parce que Rails 5.2 possède ActiveStorage. Une migration serait probablement intéressante à investiguer.

• [ ] Il me parait intéressant d'envisager un stockage sur le cloud (owncloud aujd mais nextcloud demain), via un user "collector".

  • Cela résoudrait les problèmes d'authentification derrière un controlleur (voir ci-dessous)
  • Cela résoudrait le problème de stockage (cloud == 2To).
  • Ça permettrait de récupérer les images depuis le cloud pour les autres utilisateurs (si le dossier "uploads" du cloud du user collector est partagé avec tous)!
  • Intuitivement je dirais que ça simplifierait la logique côté serveur, en tout cas cela pose la question d'avoir ou non à garder paperclip ou activestorage.

• Le collector ne donnerait plus que des URLs webdav pour que la page web puisse télécharger les images depuis le cloud.

• Lors d'un upload, le collector uploaderait vers le collector et ne stockerait pas le fichier

• Lors d'une suppression, le collector supprimerait le fichier sur le cloud

D'après la Doc de NextCloud, le download de file se fait comme suit:

GET https://user:password@example.com/remote.php/dav/files/user/path/to/file

(à mettre dans les image_tag des vues)

L'upload de file comme ceci:

PUT https://user:password@example.com/remote.php/dav/files/user/path/to/file

La suppression de file comme ceci:

DELETE https://user:password@example.com/remote.php/dav/files/user/path/to/file

N.B: en https, user:password font partie de la transaction SSL, ils ne sont pas envoyés en clair (pas de risque)

C'est un chantier qu'il ne faut à mon avis pas attaquer maintenant, mais je pense que c'est une piste sérieuse à envisager lorsque les autres points seront réglés (gestion ownertags etc).

[svergeylen]

Excellente idée :-) (ne pas oublier les performances quand on charge ~30 images de la Une, il faut que cela charge (les thumbnails du moins) en moins de ... 5 secondes ? A tenter, en tout cas)

[dvergeylen]

Il semblerait qu'il soit possible d'implémenter un nouveau Service pour ActiveStorage en implémentant cette classe abstraite!

Une implémentation naïve pourrait peut-être se faire rapidement (sans implémenter toutes les fonctions, ou en tout cas pas de façon efficiente).

[svergeylen]

je propose de d'abord faire des tests de performances en modifiant les href d'une vingtaine d'images sur une page de vergeylen.eu et de voir comment le téléchargement des photos se fait sur le cloud (rapidement ou non), (en sachant que dans ce cas là, on bypass déjà la classe abstraite en question vu qu'on hardcode les liens, c'est donc un cas plus favorable que le cas réel, mais il faudrait voir si la fluidité est au rendez-vous... ) Je pense à ca parce l'affichage des vignettes dans l'appli owncloud, c'est environ 1 minute pour 20 vignettes, même quand elles sont générées à l'avance... ) donc a priori ce serait faisable mais pas assez rapide à l'usage... (?)

[dvergeylen]

Pas con du tout!

Nextcloud devrait arriver vite, j'ai réussi à générer l'image en overlayFS ce week-end (ça m'a pris des semaines à tout comprendre, le kernel de l'image de base du tinkerboard ne le supporte pas, j'ai du documenter comment le compiler et comment installer overlay par dessus). On devrait avoir des gains de performances (→ 2Gb de RAM + Nextcloud servi par Nginx, qui peut même envoyer des trames http2 pr + de rapidité) et une robustesse à toute épreuve.