vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2020-11-19T12:04:30+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/2927Savoir sur quel serveur on est loggué2020-11-19T12:04:30+01:00Mathieu GiraudSavoir sur quel serveur on est logguéAvec le déploiement de plusieurs serveurs, certains utilisateurs peuvent avoir des comptes sur plusieurs serveurs, et, surtout dans une période de transition ou de ~"!!-crisis", utiliser l'un ou l'autre.
On devrait afficher clairement s...Avec le déploiement de plusieurs serveurs, certains utilisateurs peuvent avoir des comptes sur plusieurs serveurs, et, surtout dans une période de transition ou de ~"!!-crisis", utiliser l'un ou l'autre.
On devrait afficher clairement sur quel serveur on est (comme #2848). Un `lil` quelque part devrait suffire, et si on ne met rien on est sur le serveur public.
Généralisation de #2348 ?
Changer une couleur quelque part (argh, non, on la garde pour les clones)prod-server-lilhttps://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/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/4278Release 2020.05 et/ou déploiement sans release2020-05-07T21:56:26+02:00Mathieu GiraudRelease 2020.05 et/ou déploiement sans release
Je crois comprendre que !681 mérite une release (et ce ne sera pas la première fois qu'on en fait deux de suite).
Mais est-on sûr que les fichiers qui posaient problème marcheront ce coup-ci ? Pourrait-on imaginer un process plus agile...
Je crois comprendre que !681 mérite une release (et ce ne sera pas la première fois qu'on en fait deux de suite).
Mais est-on sûr que les fichiers qui posaient problème marcheront ce coup-ci ? Pourrait-on imaginer un process plus agile, dans lequel on s'autoriserait à déployer sur le serveur *de prod* des versions de dev à un endroit (sur `vidjil-next`, peu utilisé, voire un autre `vidjil-dev`), ce qui permettrait de vérifier rapidement que le jeu de données fonctionne, et de faire la release ensuite ? Voire, si la release prend un peu du temps (et le prendra encore plus avec process amélioré de qualification), livrer aux usagers des résultats quand c'est urgent ?
Cela pourrait être manuel (hum, dangereux, rendre plus étanche `vidjil-next` du reste ? mais permettrait de déployer une branche expérimentale pour un besoin bien précis) et/ou... déploiement continu de `dev` ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3767CloneDB : mise à jour sur vdb et lil2022-01-07T16:36:57+01:00Mathieu GiraudCloneDB : mise à jour sur vdb et lilPar crontab ou autre.
A priori moins de 24h.Par crontab ou autre.
A priori moins de 24h.2019-04-05https://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/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/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/2535Documenter ce qu'il faut pour un nouveau serveur2020-08-27T12:01:37+02:00Mathieu GiraudDocumenter ce qu'il faut pour un nouveau serveurVoir vdj#6 et vdj#330.
Je crois bien qu'il y avait quelque part des documents pour expliquer ce dont on avait besoin pour un nouveau serveur (que tu avais fait @flothoni à Necker, ou peut-être @RyanHerb) ?
Est-ce tout dans `doc/server....Voir vdj#6 et vdj#330.
Je crois bien qu'il y avait quelque part des documents pour expliquer ce dont on avait besoin pour un nouveau serveur (que tu avais fait @flothoni à Necker, ou peut-être @RyanHerb) ?
Est-ce tout dans `doc/server.org` ? D'autres documents ?https://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/2083Doc pour Ngnix2023-03-01T16:53:50+01:00Mathieu GiraudDoc pour Ngnixdoc/server.org contient les infos pour Apache (sont-elles toujours à jour ?).
Il devrait aussi y avoir quelques infos pour Nginx.
@mikael-sdoc/server.org contient les infos pour Apache (sont-elles toujours à jour ?).
Il devrait aussi y avoir quelques infos pour Nginx.
@mikael-sRyan HerbertRyan Herberthttps://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/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/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-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1475Récupérer des données par FTP/HTTP ou autre2017-11-22T12:48:32+01:00Vidjil TeamRécupérer des données par FTP/HTTP ou autreOn en parlait il y a très longtemps : on pourrait, au lieu d'uploader, donner une URL à télécharger. Cela pourrait revenir au goût du jour avec ceux qui ont des très grosses données : une transmission directe de leur serveur au notre ser...On en parlait il y a très longtemps : on pourrait, au lieu d'uploader, donner une URL à télécharger. Cela pourrait revenir au goût du jour avec ceux qui ont des très grosses données : une transmission directe de leur serveur au notre serait plus efficace qu'un upload browser.
Mais... peut-être que finalement on ne souhaite pas faciliter tant que cela l'import de fichiers de 10 GB ! Le wont-fix me tente :-)
***
@nobodyhttps://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/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/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-s