vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2020-11-13T20:03:34+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/4550task.py devrait accéder à un dictionnaire pour les (pre-, post-)process, voir...2020-11-13T20:03:34+01:00Mathieu Giraudtask.py devrait accéder à un dictionnaire pour les (pre-, post-)process, voire pour les process ?Suggestion de @duez : un dictionnaire dans `defs.py`, on ne devrait pas avoir à changer `task.py` pour un nouveau pré/post-process qui est juste "une commande à trous" (possiblement avec wrapper)
Discussion avec @duez / @flothoni : les ...Suggestion de @duez : un dictionnaire dans `defs.py`, on ne devrait pas avoir à changer `task.py` pour un nouveau pré/post-process qui est juste "une commande à trous" (possiblement avec wrapper)
Discussion avec @duez / @flothoni : les tasks demandent plus de choses... mais ne faudrait-il pas un wrapper autour de vidjil-algo ou d'autres tâches pour que ~"server-task.py" ne s'occupe que du scheduling ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/4388Supprimer le .vidjil après l'avoir inséré en base de données2020-09-30T19:01:54+02:00Mikaël SalsonSupprimer le .vidjil après l'avoir inséré en base de donnéescf. https://gitlab.inria.fr/vidjil/vdj/-/issues/1083#note_354189
Le fichier est dupliqué : il est à la fois dans le répertoire `tmp/` et également dans le répertoire `results` lorsque stocké dans la base de données. Autant le supprimer ...cf. https://gitlab.inria.fr/vidjil/vdj/-/issues/1083#note_354189
Le fichier est dupliqué : il est à la fois dans le répertoire `tmp/` et également dans le répertoire `results` lorsque stocké dans la base de données. Autant le supprimer dès qu'il est inséré (avec succès) dans la BDDhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2579Supprimer un process ne supprime pas le scheduler_task associé2020-08-07T15:43:41+02:00Ryan HerbertSupprimer un process ne supprime pas le scheduler_task associéDepuis l'interface d'un sample_set, si on supprime un `run`, on s'attendrait à ce que je le scheduler ne lance pas la tâche associée. Or je constate qu'après avoir supprimé des tâches qui étaient en `QUEUED` ou en `ASSIGNED`, les entrées...Depuis l'interface d'un sample_set, si on supprime un `run`, on s'attendrait à ce que je le scheduler ne lance pas la tâche associée. Or je constate qu'après avoir supprimé des tâches qui étaient en `QUEUED` ou en `ASSIGNED`, les entrées dans la table `scheduler_task` ne sont pas supprimées.
Je dirais même que l'on pourrait s'attendre à ce que la tâche soit complètement killée si elle est déjà en cours d'exécution.
@flothonihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4259Fuse plante parfois : “Unterminated string starting at”2020-04-29T20:35:38+02:00Mikaël SalsonFuse plante parfois : “Unterminated string starting at”Exemples le 22/04 :
* `result/tmp/out-075543//075543-37506.fuse.log`
* `result/tmp/out-075545//075545-37508.fuse.log`
* `result/tmp/out-075583//075583-37506.fuse.log`
La traceback est celle-là :
```
File "../../tools/fuse.py", line 15...Exemples le 22/04 :
* `result/tmp/out-075543//075543-37506.fuse.log`
* `result/tmp/out-075545//075545-37508.fuse.log`
* `result/tmp/out-075583//075583-37506.fuse.log`
La traceback est celle-là :
```
File "../../tools/fuse.py", line 1558, in <module>
main()
File "../../tools/fuse.py", line 1456, in main
jlist.load(path_name, args.pipeline)
File "../../tools/fuse.py", line 614, in load
self.load_vidjil(file_path, *args, **kwargs)
File "../../tools/fuse.py", line 653, in load_vidjil
self.init_data(json.load(f, object_hook=self.toPython))
File "/usr/lib/python2.7/json/__init__.py", line 291, in load
**kw)
File "/usr/lib/python2.7/json/__init__.py", line 352, in loads
return cls(encoding=encoding, **kw).decode(s)
File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python2.7/json/decoder.py", line 380, in raw_decode
obj, end = self.scan_once(s, idx)
ValueError: Unterminated string starting at: line 1 column 438022 (char 438021)
```
Comme si le fichier n'était pas complet, mais relancer le fuse fonctionne.
@magiraud @flothoni @duez déjà vu ce genre d'erreurs (avec Fuse ou autre) ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/4252Impossible de relancer une analyse effectuée2020-04-21T15:36:49+02:00Anne de SeptenvilleImpossible de relancer une analyse effectuéeJe ne sais pas si c'est voulu, mais j'ai l'impression que s'il existe un résultat pour une analyse, il n'est maintenant plus possible de relancer celle-ci (l'engrenage a disparu). Or je souhaitais reprendre d'anciens samples, que j'aurai...Je ne sais pas si c'est voulu, mais j'ai l'impression que s'il existe un résultat pour une analyse, il n'est maintenant plus possible de relancer celle-ci (l'engrenage a disparu). Or je souhaitais reprendre d'anciens samples, que j'aurais préféré d'abord réanalyser avec la dernière config (prenant en compte le consensus on random sample).https://gitlab.inria.fr/vidjil/vidjil/-/issues/3907Vérifier qu'un pre-process a le bon nombre de fichiers avant de le soumettre/...2020-03-09T11:58:41+01:00Mikaël SalsonVérifier qu'un pre-process a le bon nombre de fichiers avant de le soumettre/lancerUn peu discuté dans vdj#868 : on peut choisir un pre-process et ne pas sélectionner tous les fichiers sans que le formumlaire se plaigne.
De plus on peut imaginer la situation où l'upload d'un des deux fichiers plante.
Bref il faut vér...Un peu discuté dans vdj#868 : on peut choisir un pre-process et ne pas sélectionner tous les fichiers sans que le formumlaire se plaigne.
De plus on peut imaginer la situation où l'upload d'un des deux fichiers plante.
Bref il faut vérifier que le bon nombre de fichiers requis est dispo à la soumission et avant de lancer le pre-processMikaël SalsonMikaël Salsonhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4189Le timeout des jobs ne semble pas correspondre au temps déclaré2020-02-18T16:06:04+01:00Thonier FlorianLe timeout des jobs ne semble pas correspondre au temps déclaréEn testant une config un peu longue, je suis tombé sur un timeout.
Pour rappel, ce temps est défini dans defs.py
```
TASK_TIMEOUT = 2 * 60 * 60
```
Dans le cas de `vdb`, on avait rallongé le temps à 5h (je viens de vérifier). Or, le la...En testant une config un peu longue, je suis tombé sur un timeout.
Pour rappel, ce temps est défini dans defs.py
```
TASK_TIMEOUT = 2 * 60 * 60
```
Dans le cas de `vdb`, on avait rallongé le temps à 5h (je viens de vérifier). Or, le lancement c'est fait à 10h46, et il n'est pas encore 15h46...
Il est utilisé dans le `task.py`, lors d'un ajout
```
task = scheduler.queue_task("pre_process", args, repeats = 1, timeout = defs.TASK_TIMEOUT)
```
Est-on certain que ce paramètre est bien pris en compte dans le docker ? je ne vois pour l'heure pas d'autres raison.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3966Faire fonctionner MiXCR avec Docker2020-02-03T16:46:22+01:00Mikaël SalsonFaire fonctionner MiXCR avec DockerLorsqu'on lance MiXCR depuis un container Docker cela nécessite d'avoir java dans le container, ce qui n'est pas le cas.
À l'heure actuelle, MiXCR ne peut être lancé sur app.
Comment corriger ?Lorsqu'on lance MiXCR depuis un container Docker cela nécessite d'avoir java dans le container, ce qui n'est pas le cas.
À l'heure actuelle, MiXCR ne peut être lancé sur app.
Comment corriger ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2055Mise à jour de web2py et nouvelles fonctionnalités2020-01-22T13:56:36+01:00Mathieu GiraudMise à jour de web2py et nouvelles fonctionnalitésSuite à vidjil/vdj#299, web2py est passé de 2.9.9 à 2.14.6, avec plus de 18 mois de nouveaux développements. Mais on avait déjà, sur d'autres serveurs, des web2py plus à jour. Devrait-on avoir un mécanisme pour garantir que web2py ne res...Suite à vidjil/vdj#299, web2py est passé de 2.9.9 à 2.14.6, avec plus de 18 mois de nouveaux développements. Mais on avait déjà, sur d'autres serveurs, des web2py plus à jour. Devrait-on avoir un mécanisme pour garantir que web2py ne reste pas trop longtemps dans une vieille version ?
Les nouveautés : https://github.com/web2py/web2py/blob/master/CHANGELOG
Il y a deux fois "Improved scheduler", à voir si cela a changé quelque chose:
Parmi les prochains points prévus :
- enfin python 3 (voir #1345)
- scheduler new feature: you can now specify intervals with cron
- gluon/* removed from sys.path. Applications relying on statements like e.g. "from storage import Storage" will need to be rewritten with "from gluon.storage import Storage"
- tests can only be run with the usual web2py.py --run_system_tests OR with python -m unittest -v gluon.tests on the root dir
@mikael-s @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2349Ne pas lancer plusieurs process gourmands en mémoire en même temps2020-01-21T17:34:41+01:00Mikaël SalsonNe pas lancer plusieurs process gourmands en mémoire en même tempsMiXCR est gourmand en mémoire et si plusieurs instances sont lancées en même temps cela peut mettre la VM en carafe (cf. vdj#396). Peut-on laisser les jobs MiXCR QUEUED tant que d'autres jobs MiXCR sont en train de tourner ?
@RyanHerb...MiXCR est gourmand en mémoire et si plusieurs instances sont lancées en même temps cela peut mettre la VM en carafe (cf. vdj#396). Peut-on laisser les jobs MiXCR QUEUED tant que d'autres jobs MiXCR sont en train de tourner ?
@RyanHerb penses-tu que cela soit possible ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/4047Analyse FAILED2019-11-18T12:40:44+01:00Anne de SeptenvilleAnalyse FAILEDJ'ai 2 samples du dernier run pour lesquels l'analyse IGH a un problème. Le merge semble tout à fait normal.
Il s'agit des patient 34429 et 34430.
>Traceback (most recent call last):
File "/usr/share/vidjil/server/web2py/gluon/s...J'ai 2 samples du dernier run pour lesquels l'analyse IGH a un problème. Le merge semble tout à fait normal.
Il s'agit des patient 34429 et 34430.
>Traceback (most recent call last):
File "/usr/share/vidjil/server/web2py/gluon/scheduler.py", line 501, in executor
result = dumps(_function(*args, **vars))
File "applications/vidjil/models/task.py", line 353, in run_vidjil
run_fuse(id_file, id_config, id_data, sample_set_id, clean_before = False)
File "applications/vidjil/models/task.py", line 691, in run_fuse
stream = open(fuse_filepath, 'rb')
IOError: [Errno 2] No such file or directory: '/mnt/result/tmp/out-066735/066735-33789.fused'https://gitlab.inria.fr/vidjil/vidjil/-/issues/3213Éditer un sample qui possède un pre-process empêche de relancer une analyse d...2019-09-24T11:20:32+02:00Mikaël SalsonÉditer un sample qui possède un pre-process empêche de relancer une analyse dessusQuand on édite un fichier possédant un pre-process, le `sequence_file.pre_process_flag` passe à `WAIT` ce qui affiche le pre-process comme étant « `QUEUED` » (ce qui n'est d'ailleurs pas le cas). Cet état empêche ensuite de (re)lancer to...Quand on édite un fichier possédant un pre-process, le `sequence_file.pre_process_flag` passe à `WAIT` ce qui affiche le pre-process comme étant « `QUEUED` » (ce qui n'est d'ailleurs pas le cas). Cet état empêche ensuite de (re)lancer toute analyse sur ce fichier, puisque l'analyse se met en état « STOPPED » attendant que le pre-process se finisse (ce qui n'arrivera jamais… puisqu'aucun pre-process n'a été relancé).
Éditer un fichier avec un pre-process, ne devrait pas toucher à l'état du `pre_process_flag` (à moins qu'on ait vraiment changé des choses sur le pre-process utilisé).https://gitlab.inria.fr/vidjil/vidjil/-/issues/3558Scheduler : Error cleaning up2019-08-22T13:37:33+02:00Ryan HerbertScheduler : Error cleaning upOn a des erreurs régulières dans nos workers de la forme `ERROR:web2py.scheduler.28fe17984f96#17:Error cleaning up`.
De ce que j'ai compris [ici](https://groups.google.com/d/msg/web2py/opWFUcDMCyc/pMD0wFPkz9UJ), celà veut dire que le sc...On a des erreurs régulières dans nos workers de la forme `ERROR:web2py.scheduler.28fe17984f96#17:Error cleaning up`.
De ce que j'ai compris [ici](https://groups.google.com/d/msg/web2py/opWFUcDMCyc/pMD0wFPkz9UJ), celà veut dire que le scheduler n'arrive pas à agir sur ses propre tables.
Se pourrait-il que cette erreur de se produise sur une partie des workers de manière quasi-continue, et de temps en temps sur la totalité des workers (ce qui entraine l'erreur avec tous les jobs en `QUEUED`).https://gitlab.inria.fr/vidjil/vidjil/-/issues/3862Analyse FAILED avec un résultat2019-03-25T11:12:45+01:00Anne de SeptenvilleAnalyse FAILED avec un résultatCette analyse étais notée FAILED à côté du nom du sample, et pourtant il semble bien y avoir un résultat (obtenu à 16h04) j'ai relancé l'analyse à 16h27 avant de voir que ça avait quand même fonctionné (?).
https://vdb.vidjil.org/brow...Cette analyse étais notée FAILED à côté du nom du sample, et pourtant il semble bien y avoir un résultat (obtenu à 16h04) j'ai relancé l'analyse à 16h27 avant de voir que ça avait quand même fonctionné (?).
https://vdb.vidjil.org/browser/index.html?set=30585&config=54https://gitlab.inria.fr/vidjil/vidjil/-/issues/3785Combo -FaW obsolète2019-03-12T14:08:29+01:00Mathieu GiraudCombo -FaW obsolèteC'est une conséquence malheureuse de !434 (peut-être la plus pénible sur l'ensemble des tests changés): la combo `-FaW` devient `--out-reads --label-filter --label`... c'est lourd (et même si on mettait `--filter` au lieu de `--label-fil...C'est une conséquence malheureuse de !434 (peut-être la plus pénible sur l'ensemble des tests changés): la combo `-FaW` devient `--out-reads --label-filter --label`... c'est lourd (et même si on mettait `--filter` au lieu de `--label-filter`).
Voir #3305, et la combo est aussi mentionnée ou utilisée dans `vidjil-algo.md` et dans `task.py` pour #1469.
On pourrait faire aussi un raccourci pour ces trois options, mais je ne suis pas sûr que cela aide à la compréhension de l'ensemble. Bref tant pis ?Algo 2018.12https://gitlab.inria.fr/vidjil/vidjil/-/issues/3538Réflexion sur les lancements (post-)post-process2019-03-05T15:10:14+01:00Mathieu GiraudRéflexion sur les lancements (post-)post-processOn a des choses à lancer après nos process: #1469 #1744 #3181 #1567
Certaines choses (#1469, #3181 ?) pourraient se lancent via le ~"server-fuse", d'autres vraiment après, parfois non systématiquement, sur demande de l'usager (#1744, ~"...On a des choses à lancer après nos process: #1469 #1744 #3181 #1567
Certaines choses (#1469, #3181 ?) pourraient se lancent via le ~"server-fuse", d'autres vraiment après, parfois non systématiquement, sur demande de l'usager (#1744, ~"app\-clonedb" plus poussé, #1567...). On devrait discuter d'un mécanisme pour au moins ce dernier cas.https://gitlab.inria.fr/vidjil/vidjil/-/issues/1817Indicateur de progression / tâches en cours pour ce qui est lancé par task.py2019-02-28T12:40:31+01:00Vidjil TeamIndicateur de progression / tâches en cours pour ce qui est lancé par task.pyPour les grosse tâches qui durent longtemps (10 min → 2/3 heures), ce serait bien d’avoir un RUNNING (40%).
Voir par exemple http://web2py.com/books/default/chapter/29/04/the-core#Reporting-progress-percentages dans la doc web2py avec `s...Pour les grosse tâches qui durent longtemps (10 min → 2/3 heures), ce serait bien d’avoir un RUNNING (40%).
Voir par exemple http://web2py.com/books/default/chapter/29/04/the-core#Reporting-progress-percentages dans la doc web2py avec `sync_output`.
Mais bof, suppose de perdre la stdout… Ou bien pas de !clear, mais un parsing maison de la stdout, quitte à faire évoluer cette stdout du C++ ?
Et ensuite, c’est difficile de prédire le temps total. Peut-être, pour Vidjil, plutôt `RUNNING 1 (40%)` puis `RUNNING 2 (30%)` ou `CLUSTERING` ou autre chose.
(Et cela dépend du soft, MiXCR ce sera autre chose...)
https://gitlab.inria.fr/vidjil/vidjil/-/issues/1520Liste des sets : info si les calculs sont finis ou pas2019-02-28T12:39:27+01:00Vidjil TeamListe des sets : info si les calculs sont finis ou pasLorsqu'on a lancé beaucoup de calculs (disons sur 70 patients par exemple), on aimerait savoir si c'est fini ou pas, ou au moins quels patients on pourrait consulter. Une manière simple de visualiser cela serait d'avoir un petit indicate...Lorsqu'on a lancé beaucoup de calculs (disons sur 70 patients par exemple), on aimerait savoir si c'est fini ou pas, ou au moins quels patients on pourrait consulter. Une manière simple de visualiser cela serait d'avoir un petit indicateur dans la liste des configs de chaque patient lorsque la config est en train de tourner.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3621Ne pas lancer des fuse sans fichier2018-11-21T16:11:12+01:00Mathieu GiraudNe pas lancer des fuse sans fichiervdj#754
Discussion avec @mikael\-s, @flothoni, @RyanHerb : le `files` de ~"server-task.py" est vide dans certains cas:
https://gitlab.inria.fr/vidjil/vidjil/blob/dev/server/web2py/applications/vidjil/models/task.py#L628
car si on a sup...vdj#754
Discussion avec @mikael\-s, @flothoni, @RyanHerb : le `files` de ~"server-task.py" est vide dans certains cas:
https://gitlab.inria.fr/vidjil/vidjil/blob/dev/server/web2py/applications/vidjil/models/task.py#L628
car si on a supprimé des fichiers, y compris tout, on relance.
- ne pas relancer un `fuse` si on a supprimé tout... mais difficile à détecter ?
- dans tous les cas (et peut-être cela suffira) failsafe dans `run_fuse`, si `files` est videhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3626`compute_extra` plante s'il n'y a pas de clone2018-11-13T18:11:20+01:00Mikaël Salson`compute_extra` plante s'il n'y a pas de clone```
Traceback (most recent call last):
File "/home/vidjil/git/server/vidjil/server/web2py/gluon/scheduler.py", line 501, in executor
result = dumps(_function(*args, **vars))
File "applications/vidjil/models/task.py", line 331, in...```
Traceback (most recent call last):
File "/home/vidjil/git/server/vidjil/server/web2py/gluon/scheduler.py", line 501, in executor
result = dumps(_function(*args, **vars))
File "applications/vidjil/models/task.py", line 331, in run_vidjil
compute_extra(id_file, id_config, 5)
File "applications/vidjil/models/task.py", line 111, in compute_extra
for clone in d["clones"]:
TypeError: 'NoneType' object is not iterable
```