vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2017-05-22T15:25:32+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/2086Serveur anormalement lent2017-05-22T15:25:32+02:00Thonier FlorianServeur anormalement lentDemande de Patrick : Le serveur semble être très très lent.
Je viens de regarder pour m'y connecter et faire un petit test voir si le débit de mon côté était aussi impacté.
Le résultat est que les pages sont effectivement lentes à ch...Demande de Patrick : Le serveur semble être très très lent.
Je viens de regarder pour m'y connecter et faire un petit test voir si le débit de mon côté était aussi impacté.
Le résultat est que les pages sont effectivement lentes à chargées (de l'ordre de la minute pour ouvrir le page d'identification), on finit timeout majoritairement
Je ne vois pas de surplus au niveau de la charge de travail du serveur.
4 active worker, rien en attente ou en cours de run, charge moyenne en dessous des 1%.
L'espace disque est bon aussi.
Il y a bien quelques erreurs dans le log, mais rien qui ne me semble du genre a créer un tel dysfonctionnement (you do not have permission to launch process for this config, missing id, permission necessaire pour des suppression)
Il y a en revanche quelques erreurs propres à web2py (d'hier et du jour) mais je n'y ai pas accès, et les lenteurs remontent au début de semaine d'après Patrick.
Je ne sais pas si ça vient des processus vidjil ou de implémentation du serveur.
En tout cas, c'est assez urgent de régler le souci, mais je ne sais pas quoi faire de ces erreurs.
@RyanHerb @magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1146Augmenter le nombre de CPU pouvant être utilisés sur le serveur2017-11-22T12:48:31+01:00Vidjil TeamAugmenter le nombre de CPU pouvant être utilisés sur le serveurIl y a de la marge sur le serveur, on peut au moins avoir 2 Vidjil lancés en parallèle et même 3 en regardant l'utilisation du serveur sur le manager OVH (mais pas 4 !)
***
on passe a 3 workers (en attendant que vidjil soit multi-thread)...Il y a de la marge sur le serveur, on peut au moins avoir 2 Vidjil lancés en parallèle et même 3 en regardant l'utilisation du serveur sur le manager OVH (mais pas 4 !)
***
on passe a 3 workers (en attendant que vidjil soit multi-thread)
***
merci !
Est-ce que finalement Vidjil a besoin d'être multi-thread, si on en lance toujours plein en même temps :) ?
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3432Les test_server_functional Docker peuvent saturer l'espace disque2019-11-22T12:06:13+01:00Mathieu GiraudLes test_server_functional Docker peuvent saturer l'espace disquehttps://gitlab.inria.fr/vidjil/vidjil/-/jobs/151369
Plus généralement, est-ce que containers provenant des nouveaux tests sont nettoyés de temps en temps ?
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/jobs/151369
Plus généralement, est-ce que containers provenant des nouveaux tests sont nettoyés de temps en temps ?
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1099Log2017-11-22T12:48:31+01:00Vidjil TeamLogAvoir quelque part un log des actions de nos utilisateurs.
Mécanisme de log de web2py ? de python ?
Dans un fichier texte simple ?
Voire dans la database ? (dommage si database tombe :)
***
Le log est très important, même si on n'a pas...Avoir quelque part un log des actions de nos utilisateurs.
Mécanisme de log de web2py ? de python ?
Dans un fichier texte simple ?
Voire dans la database ? (dommage si database tombe :)
***
Le log est très important, même si on n'a pas d'interface pour le voir.
***
le log de web2py par defaut se trouve dans vidjil/server/web2py/httpserver.log
il donne des infos sur l'ip / la date / le controller appelé
***
9cb95de / 7364756 → /var/vidjil/vidjil.log
***
@mikael-s @Duez @magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4418Réparer le déploiement continu du client, via Docker2022-11-10T17:23:57+01:00Mathieu GiraudRéparer le déploiement continu du client, via Docker
En plus de #4417, faire que cela se déploie sur `app` pour tout push sur `prod-client`.
cc @duez
En plus de #4417, faire que cela se déploie sur `app` pour tout push sur `prod-client`.
cc @duezmarc duezmarc duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2792URL : rewrite nginx pour de belles URL2020-06-18T16:41:58+02:00Mathieu GiraudURL : rewrite nginx pour de belles URL`http://app.vidjil.org/1471#3?foo=bar`
devrait être renommé, après nginx, en
`http://app.vidjil.org/browser?set=1471&n=3&foo=bar`
Pas de ~bikeshedding ici, voir #2095 pour cela.
cc @RyanHerb`http://app.vidjil.org/1471#3?foo=bar`
devrait être renommé, après nginx, en
`http://app.vidjil.org/browser?set=1471&n=3&foo=bar`
Pas de ~bikeshedding ici, voir #2095 pour cela.
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2046Nom du serveur dans modules/defs.py2023-03-01T16:26:47+01:00Mathieu GiraudNom du serveur dans modules/defs.pyIl y a plusieurs références en dur à app.vidjil.org (voir b716a4c).
Un item de configuration dans defs.py serait plus approprié.
@RyanHerb @mikael-sIl y a plusieurs références en dur à app.vidjil.org (voir b716a4c).
Un item de configuration dans defs.py serait plus approprié.
@RyanHerb @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1127Erreur 404 propre2017-11-22T12:48:31+01:00Vidjil TeamErreur 404 proprehttp://rbx.vidjil.org/bidule produit une invalid request → 404
***
Si j'étais pointilleux je dirais que les erreurs 400 invalid request (controlleur inconnu) et 404 (page inconnu) sont différentes mais je ne le suis pas donc toutes les e...http://rbx.vidjil.org/bidule produit une invalid request → 404
***
Si j'étais pointilleux je dirais que les erreurs 400 invalid request (controlleur inconnu) et 404 (page inconnu) sont différentes mais je ne le suis pas donc toutes les erreur de ce type (400/404/415/422/502) sont maintenant redirigées sur 404.
>> 8a465c306feede0efe
***
@mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1027makefile global2017-11-22T12:48:31+01:00Vidjil Teammakefile global
***
#1025
***
#1025https://gitlab.inria.fr/vidjil/vidjil/-/issues/1026makefile server2017-11-22T12:48:32+01:00Vidjil Teammakefile server
***
#1025
***
#1025https://gitlab.inria.fr/vidjil/vidjil/-/issues/1025Script de déploiement / packages utilisés2017-11-22T12:48:32+01:00Vidjil TeamScript de déploiement / packages utilisésIl faudra qu'un jour on aie une intégration continue complète (script d'install depuis une 14.04 LTS). En attendant, il faut des à présent noter quelque part :
- tous les packages installés
- les commandes d'install / mkdir / make ut...Il faudra qu'un jour on aie une intégration continue complète (script d'install depuis une 14.04 LTS). En attendant, il faut des à présent noter quelque part :
- tous les packages installés
- les commandes d'install / mkdir / make utilisées
***
fichier /root/log (ou Marc, tu peux mettre cela où tu veux)
***
à voir en décembre / janvier avec le packaging
***
#1026, #1027
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2062Authentification par LDAP2021-10-22T11:07:25+02:00Thonier FlorianAuthentification par LDAPEvoqué au CHU de Rennes :
Possibilité de passer par un system d'authentification par LDAP.
Celui-ci permettrait de révoquer ou autoriser les accès plus simplement sans avoir à gérer la création de compte pour l'admin local.
D'après ...Evoqué au CHU de Rennes :
Possibilité de passer par un system d'authentification par LDAP.
Celui-ci permettrait de révoquer ou autoriser les accès plus simplement sans avoir à gérer la création de compte pour l'admin local.
D'après eux, relativement répandu comme système de gestion des accès. Cela dit, pas obligatoire du tout.
Pour l'application à Vidjil, il faudrait quand meme que l'ensemble des comptes pointent vers un meme groupe d'utilisateurs pour partager les données et résultats de patients.
@magiraud @mikael-s @RyanHerbmarc duezmarc duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4Web application - Server2019-04-03T07:49:46+02:00Mathieu GiraudWeb application - ServerWe develop a sample database that allows users to upload sequence files and manage their jobs directly from the client. We look for efficiency, robustness, and security, and propose a full-stack environment, making use of many tools to e...We develop a sample database that allows users to upload sequence files and manage their jobs directly from the client. We look for efficiency, robustness, and security, and propose a full-stack environment, making use of many tools to ensure the system is healthy and suitable for use in a professional environment.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3624Garder les fichiers bruts tels qu'uploadés ?2021-03-17T09:35:49+01:00Mikaël SalsonGarder les fichiers bruts tels qu'uploadés ?Beaucoup de tâches FAILED ces derniers temps : une hypothèse serait des problèmes avec Pear. Le problème c'est qu'après le pre-process on n'a plus accès aux fichiers d'origine pour reproduire un éventuel problème.
Faudrait-il conserver ...Beaucoup de tâches FAILED ces derniers temps : une hypothèse serait des problèmes avec Pear. Le problème c'est qu'après le pre-process on n'a plus accès aux fichiers d'origine pour reproduire un éventuel problème.
Faudrait-il conserver les fichiers tels qu'ils ont été uploadés ? Au moins quelques jours pour éviter de saturer l'espace disque ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/1588Récupérer des données par FTP/HTTP/NFS ou autre2017-11-22T12:48:32+01:00Vidjil TeamRécupérer des données par FTP/HTTP/NFS ou autreLe serveur doit pouvoir récupérer des fichiers à distance (par FTP/HTTP). La première étape est d'avoir un contrôleur qui permet ça (pour que des scripts puissent y accéder au moins). Ensuite on pourrait l'exposer dans l'interface (file/...Le serveur doit pouvoir récupérer des fichiers à distance (par FTP/HTTP). La première étape est d'avoir un contrôleur qui permet ça (pour que des scripts puissent y accéder au moins). Ensuite on pourrait l'exposer dans l'interface (file/edit_form).
***
Marc avait l'air motivé, merci :)
***
Et on peut avoir deux versions : une qui récupère le fichier à l'URL donnée et l'autre qui ne stocke que l'URL.
Ensuite Vidjil sera lancé directement avec l'URL : ça marche déjà en utilisant la puissance de bash (sh ?) :
./vidjil -e all -G germline/IGH <(wget -O - -q http://www.vidjil.org/seqs/Stanford_S22.fasta)
(le -e all est là pour éviter l'estimation du nombre de reads)
***
Discuté à l'instant : pour que l'e-value fonctionne, on pourrait
- soit wrapper dans un scipt shell pour vraiment avoir le fichier
- soit avoir un nb de reads par défaut (1 milllion)
- soit estimer ce nb de reads de l'extérieur (taille du fichier), et le passer en ligne de commande
L'estimation peut être à la louche, à un facteur 10 ou 100 près :)
***
@DuezWeb 2017.03Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1448Séparation serveurs : app (html/js) // vda2017-11-22T12:48:32+01:00Vidjil TeamSéparation serveurs : app (html/js) // vdaFaudrait-il séparer (physiquement, virtuellement) les serveurs ?
- un qui ne fait que la db + browser
- un autre pour upload / vidjil, qui peut éventuellement ramer, mais qui ne bloque pas l'interaction des users avec la db et le b...Faudrait-il séparer (physiquement, virtuellement) les serveurs ?
- un qui ne fait que la db + browser
- un autre pour upload / vidjil, qui peut éventuellement ramer, mais qui ne bloque pas l'interaction des users avec la db et le browser
Juste une réflexion, on ne va pas se lancer là-dedans pour l'instant ! Et en plus, en production, ce n'est même pas dit que nos pb d'efficacité soient si importants, typiquement dans un hôpital il y aura 1 ou 2 utilisateurs, pas 100 simultanés :)
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1447Upload et 'Could not connect to database'2017-11-22T12:48:32+01:00Vidjil TeamUpload et 'Could not connect to database'Ce matin, j'ai eu un certain nombre de "Could not connect to database, please retry"... alors que la seule opération en cours était de l'upload par Lille. Massif certes, mais normalement ce n'est toujours que 2 fichiers à la fois. (Quoiq...Ce matin, j'ai eu un certain nombre de "Could not connect to database, please retry"... alors que la seule opération en cours était de l'upload par Lille. Massif certes, mais normalement ce n'est toujours que 2 fichiers à la fois. (Quoique, si plusieurs clients...)
Serait-ce souhaitable et possible d'isoler un peu plus l'upload côté serveur ?
Dans des workers dédiés ? Une autre solution ?
***
En repassant sur le serveur un peu plus tard, alors que celui-ci travaille bcp (plusieurs vidjil lancés, d'autres en attentes), mais pas d'upload, cela fonctionne bien mieux...
C'est une impression de ma part ou c'est vraiment l'upload qui est le facteur limitant pouvant ralentir le serveur ?
***
baissé. Sera fermé mi mai, on a moins de soucis en ce moment ?
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1098Expiration des fichiers .fasta2017-11-22T12:48:32+01:00Vidjil TeamExpiration des fichiers .fastaAu bout d'un moment, on pourrait supprimer des fichiers.
(Cela ne choquait pas Martin qu'on ne garde pas tout)
Peut-être en prévenant par mail avant les utilisateurs.
***
6857522
***
@DuezAu bout d'un moment, on pourrait supprimer des fichiers.
(Cela ne choquait pas Martin qu'on ne garde pas tout)
Peut-être en prévenant par mail avant les utilisateurs.
***
6857522
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2007Empêcher l'upload ou de lancer des jobs lorsqu'il ne reste plus assez d'espac...2020-01-08T17:39:47+01:00Vidjil TeamEmpêcher l'upload ou de lancer des jobs lorsqu'il ne reste plus assez d'espace disqueOn sait où les séquences et les résultats sont stockés. Si on passe en dessous d'un seuil d'espace libre pour un de ces emplacements, il faut empêcher l'upload ou le run (c-à-d. avoir un test en plus dans VidjilAuth ?). De cette façon on...On sait où les séquences et les résultats sont stockés. Si on passe en dessous d'un seuil d'espace libre pour un de ces emplacements, il faut empêcher l'upload ou le run (c-à-d. avoir un test en plus dans VidjilAuth ?). De cette façon on ne se retrouve jamais avec un disque plein et pas avec des jobs en failed parce qu'il n'y a plus d'espace disque.
Par contre, prévoir de spammer les admins dès que la limite est atteinte pour qu'ils fassent quelque chose (en générant un ticket web2py ?)
***
C'est en prod. On a une limite en pourcentage qui se fixe dans defs.py. Actuellement réglé sur 1%. La limite est commune pour toutes les partitions mais la vérification est spécifique (donc il peut s'avérer que l'upload soit bloqué, mais pas les runs
***
Merci Ryan.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1662Supervision externe du serveur de prod / tests fonctionnels live2017-11-22T12:48:32+01:00Vidjil TeamSupervision externe du serveur de prod / tests fonctionnels liveEn faisant un "apt-get upgrade", je me demande toujours si tout fonctionne.
Même le jour où notre déploiement git>prod sera automatisé, on aura toujours besoin de superviser le serveur, il y a plein de raisons qui peuvent faire que quel...En faisant un "apt-get upgrade", je me demande toujours si tout fonctionne.
Même le jour où notre déploiement git>prod sera automatisé, on aura toujours besoin de superviser le serveur, il y a plein de raisons qui peuvent faire que quelque chose tombe.
La supervision externe vérifie déjà que le serveur tourne et que les derniers jobs ne sont pas en "queued", c'est déjà pas mal.
J'aimerais avoir un truc plus complet, un test fonctionnel (qui uploade une séquence, lance un run, et compare les résultats ?). On pourrait avoir un utilisateur test qui travaillerait sur un patient test *sur le serveur de prod*.
***
@magiraud @RyanHerb @mikael-s