Je fais dans ce post un retour utilisateur que j’ai reçu lors d’un atelier d’initiation à Yunohost, à Rennes lors du FDLN 2020. Un manque identifié lors du choix des applications à installer sur son yunohost est l’absence d’indication sur les ressources nécessaires à leur fonctionnement.
En effet, si on n’est pas expert sur les logiciels et les technologies embarquées par les applis, difficile de savoir si elles vont tourner sur un mini-VPS avec peu de RAM, ou bien si l’espace disque restant est suffisant pour l’installer.
Est-ce que la question a déjà été soulevée ? Quelles sont vos manières de procéder sur vos serveurs, pour le choix de nouvelles apps ? La page de choix d’application est déjà bien chargée (et assez claire, merci pour le design !), du coup je me demande où/quand présenter ces informations.
On pourrait p-e demander aux packagers d’inclure des infos qualitatives dans le manifest.json ?
Je pense que c’est une super idée. (Je ne sais pas si la question a déjà été posée.)
Cela demande du travail, mais on peut déjà donner un ordre idée de la consommation de chaque app (comme un niveau de 1 à 10 comme les apps, où 1 serait une consommation basse à 10 qui serait une application consommant beaucoup ).
Inclure cela dans le manifest ne devrait pas être trop difficile, après, le mieux serait, de la même manière que pour les apps, de développer une application de supervision (mais très certainement qu’il y en a plein) qui pourrait automatiser le processus (ou utiliser également le CI pour ça – dans les tests CI l’app est déjà installée).
Oui, c’est très subjectif/case-dependent, mais il faudrait une première approche, pour ne pas laisser les primo-utilisateurs dans le flou. Moi je verrai bien une simple échelle de 0 à 3 :
Quasi pas d’impact (genre custom_webapp)
Impact faible, peut s’installer avec d’autres, même sur une ARM
Impact fort, (>1Go RAM libre par exemple)
Impact critique, lisez-en plus avant d’installer (installation de node ou Docker par exemple, ou variation selon nb_users importante)
On écrit un peu de contexte pour permettre aux packagers de se situer, et on fait un fil de REX sur le forum pour compléter
Totalement interesse aussi par ce genre d’informations. Personnellement, je pense qu’il pourrait etre interessant de faire un classement par type de materiel representatif. Par exemple:
Raspberry Pi 3: bien utilisable (chargement initial un peu long), conseille pour 4 utilisateurs maximum
VPS OVH (2GiB RAM, 2Ghz CPU): parfaitement utilisable, commence a ralentir a partir de 10 utilisateurs
Je realise qu’il est difficile de definir des mesures qui ne soient pas subjectives (comme le disait @Jaxom99) mais en croisant avec du materiel representatif, on pourrait s’en sortir.
PS: y-a-t-il des stats sur le materiel sur lequel Yunohost tourne (par exemple sur le modele de ce que fait LineageOS?
@Vinz Je pense qu’aucun matériel est réellement représentatif. Par exemple, au niveau des boards ARM, Yunohost supporte les boards Olimex Lime1 et Lime2 qui ont moins de ressources que le Raspberry Pi 3. Et à ma connaissance, il n’y a aucune donnée collectée par Yunohost, donc pas de statistiques.
Mais comme dit @ljf, je serais pour un minimum requis de ressources qui pourrait être calculé par application (à voir si c’est automatisable ou si les packagers doivent manuellement l’indiquer).
Ce calcul pourrait aussi englober les ressources prises par les dépendances de l’application. Par exemple, Yunohost a par défaut MariaDB (anciennement MySQL) comme système de gestion de base de donnée (SGBD). En imaginant qu’une application nécessite l’installation de PostgreSQL, on pourrait englober le minimum de ressources requis pour ce SGBD dans le calcul total du minimum de ressources requises.
Mais ça reste compliqué de réaliser un système “intelligent” de manière fiable. L’intention derrière ces idées est excellente, mais il y a beaucoup de variables à prendre en compte :
la quantité totale de ressources (CPU, RAM, espace disque, etc);
les ressources libres (que faire si Yunohost est sous une charge inhabituelle ?);
le nombre d’utilisateurs prévus (en sachant que, selon ce nombre et l’application concernée, la consommation de ressources n’augmentent pas proportionnellement);
l’architecture du matériel;
le débit de la connexion à Internet (Jitsi peut-être très gourmand, par exemple);
Merci à vous pour ces premiers retours On en a discuté en réunion contributeurs et bien évidemment, ca soulève plein de questions, de trucs à faire/refaire, etc… Mais ce qui est sûr c’est qu’on a besoin de plus de retour d’utilisateur·ices sur ça !
Donc on va commencer simple, et on verra jusqu’où aller dans la complexité (sans trop embêter les packageurs bénévoles ni surcharger la Core Team !). Pour débuter : un tableau de retours d’expérience sur vos apps installées
L’idée c’est de remplir 1 ligne par app et par config, pour voir qu’est-ce qui a compté pour vous, comment ça a marché (ou pas), et donc quelle information on va devoir communiquer avant l’installation !
Le format peut évoluer, il est en trois sections :
Consommations de l’application, en usage régulier
Configuration du serveur, avec le nombre d’utilisateurs de l’application
Commentaires sur votre expérience d’installation et d’usage, l’intérêt ou non du Readme.md du package…
Je vous propose aussi de “noter” subjectivement l’impact en ressources de l’appli entre 0 et 3, selon le barème de ce post, pour voir si c’est pertinent ou si les évaluations sont trop disparates.
Les échanges peuvent continuer dans ce fil, si vous avez des questions/suggestions à faire sur le format
Merci à tous pour votre aide, améliorons ensemble Yunohost !
à leur fonctionnement.
Quasi pas d’impact (genre custom_webapp)
Impact faible, peut s’installer avec d’autres, même sur une ARM
Impact fort, (>1Go RAM libre par exemple)
Impact critique, lisez-en plus avant d’installer (installation de node ou Docker par exemple, ou variation selon nb_users importante)
