vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2019-05-24T18:12:55+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/3920Supprimer les permissions associées quand on supprime une entrée2019-05-24T18:12:55+02:00Mikaël SalsonSupprimer les permissions associées quand on supprime une entréePermettrait d'éviter le genre de problème rencontré dans vdj#587 (https://gitlab.inria.fr/vidjil/vdj/issues/587#note_68238).Permettrait d'éviter le genre de problème rencontré dans vdj#587 (https://gitlab.inria.fr/vidjil/vdj/issues/587#note_68238).https://gitlab.inria.fr/vidjil/vidjil/-/issues/2352Le contrôleur load_backup echoue2017-10-31T14:26:09+01:00Ryan HerbertLe contrôleur load_backup echoueLa fonction de restauration à partir d'un fichier csv échoue sur une clef étrangère.
`Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/gluon/restricted.py", line 227, in restricted
exec ccode in environmen...La fonction de restauration à partir d'un fichier csv échoue sur une clef étrangère.
`Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/gluon/restricted.py", line 227, in restricted
exec ccode in environment
File "/usr/share/vidjil/server/web2py/applications/vidjil/controllers/default.py", line 736, in <module>
File "/usr/lib/python2.7/dist-packages/gluon/globals.py", line 412, in <lambda>
self._caller = lambda f: f()
File "/usr/share/vidjil/server/web2py/applications/vidjil/controllers/default.py", line 182, in init_from_csv
db.import_from_csv_file(open(defs.DB_BACKUP_FILE, 'rb'))
File "/usr/lib/python2.7/dist-packages/gluon/packages/dal/pydal/base.py", line 1097, in import_from_csv_file
*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/gluon/packages/dal/pydal/objects.py", line 941, in import_from_csv_file
curr_id = self.insert(**dict(items))
File "/usr/lib/python2.7/dist-packages/gluon/packages/dal/pydal/objects.py", line 712, in insert
ret = self._db._adapter.insert(self, self._listify(fields))
File "/usr/lib/python2.7/dist-packages/gluon/packages/dal/pydal/adapters/base.py", line 739, in insert
raise e
IntegrityError: (1452, u'Cannot add or update a child row: a foreign key constraint fails (`vidjil`.`scheduler_run`, CONSTRAINT `scheduler_run_ibfk_1` FOREIGN KEY (`task_id`) REFERENCES `scheduler_task` (`id`) ON DELETE CASCADE)')`https://gitlab.inria.fr/vidjil/vidjil/-/issues/4617Message d'alerte : revoir la CSS2021-02-05T20:02:50+01:00Mikaël SalsonMessage d'alerte : revoir la CSSLe message d'alerte n'est pas affiché quand il est trop long (car caché). On n'a vraiment pas envie d'être embêté par ce genre de problème quand on affiche un message d'alerte.Le message d'alerte n'est pas affiché quand il est trop long (car caché). On n'a vraiment pas envie d'être embêté par ce genre de problème quand on affiche un message d'alerte.marc duezmarc duez2021-01-15https://gitlab.inria.fr/vidjil/vidjil/-/issues/2924deploy-docker // installation et mise à jour Docker sur un serveur de prod2020-02-20T11:43:12+01:00Mathieu Girauddeploy-docker // installation et mise à jour Docker sur un serveur de prodStage manuel, en fin de pipeline, après #2940.
Pour l'instant déjà le ~client.
cc @RyanHerbStage manuel, en fin de pipeline, après #2940.
Pour l'instant déjà le ~client.
cc @RyanHerbprod-server-lilRyan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3875Deux personnes peuvent acceder au même sample/run en même temps2019-03-25T15:31:30+01:00Thonier FlorianDeux personnes peuvent acceder au même sample/run en même tempsOn devrait éclaircir le comportement en cas ou l'on est plusieurs personnes à accéder au même fichier.
Je ne sais pas la mécanique à mettre en place. C'est probablement assez compliqué. Je me demande si l'on ne devrait pas avoir un sock...On devrait éclaircir le comportement en cas ou l'on est plusieurs personnes à accéder au même fichier.
Je ne sais pas la mécanique à mettre en place. C'est probablement assez compliqué. Je me demande si l'on ne devrait pas avoir un socket ou une session pour savoir si un fichier est déjà accéder par quelque qu'un d'autre.
Il faudrait s'inspirer des autres logiciels du même genre, ou des règles de dev en vigueur. Vous avez des idées ?
@magiraud @mikael\-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3649Docker : ne pas les lancer avec l'utilisateur root2018-11-30T18:32:51+01:00Mikaël SalsonDocker : ne pas les lancer avec l'utilisateur rootCela éviterait des soucis comme #3638 (et probablement d'autres).Cela éviterait des soucis comme #3638 (et probablement d'autres).https://gitlab.inria.fr/vidjil/vidjil/-/issues/2161Logger toutes les commandes lancées sur un serveur de prod2021-01-06T16:00:44+01:00Mikaël SalsonLogger toutes les commandes lancées sur un serveur de prod[How can you log every command typed](https://unix.stackexchange.com/questions/86000/how-can-you-log-every-command-typed)
Suggestions:
* `auditd`
* `script`
cc @RyanHerb @magiraud[How can you log every command typed](https://unix.stackexchange.com/questions/86000/how-can-you-log-every-command-typed)
Suggestions:
* `auditd`
* `script`
cc @RyanHerb @magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4419Taille des sorties / utilisation du disque dans un serveur, particulièrement ...2020-07-31T17:52:24+02:00Mathieu GiraudTaille des sorties / utilisation du disque dans un serveur, particulièrement en -y allBeaucoup d'issues ces derniers temps sur la taille des sorties et l'occupation du disque en `-y all`.
Issue ici pour faire le point, que ce soit sur les choses déjà faites ou les choses possibles.
cc @flothoni @mikael-s
Sur un lanceme...Beaucoup d'issues ces derniers temps sur la taille des sorties et l'occupation du disque en `-y all`.
Issue ici pour faire le point, que ce soit sur les choses déjà faites ou les choses possibles.
cc @flothoni @mikael-s
Sur un lancement de `vidjil-algo`, indépendament de tout ~server :
- --no-windows, --no-airr, --no-windows #3861
- clone.fa #4386
- .vdj.fa #4387 (et #3795)
- .vidjil allégé #4036 (#4334, #4343)
- .vidjil.gz #4253
Sur interaction avec ~"server-database" / ~"server-hosting" :
- vijdil.gz #2015 (après #4254)
- supprimer .vidjil après insertion dans db #4388
- nettoyer régulièrement `/tmp/` vdj#1083.
Documenter également cela:
- pour vidjil-algo, 1 sample
- pour "server requirements"
Avec 2020.06, sur `-g germline/homo-sapiens.g -r 1 -y all` (pas fait `-3` ou autre, mais cela devrait être négligeable)
Autres colonnes/lignes bienvenues.
| | S22 | L3.0 | lil #4386
| ---- | ------ | ------ | ------ |
| *.fasta.gz* |*405 KB*| -- |
| *.fastq.gz* | -- |*308 MB*|
| .vidjil | 16 MB | 180 MB |
| .tsv | 3.3 MB | 30 MB |
| .vdj.fa | 3.5 MB | 56 MB |
| .windows.fa | 726 KB | 7.1 MB |
| seq/* | 43 MB | 415 MB | 15.1 GB
| total | 66 MB | 687 MB | 27.3 GB
| ---- | ------ | ------ |
| .vidjil.gz | 980 K | 15 MB |
Et .edges et .log sont négligeables.
(au passage, `--gz` et gzip du fichier .vidjil donnent en gros la même taille... mais pas exactement le même fichier)https://gitlab.inria.fr/vidjil/vidjil/-/issues/3627Checksum des fichiers uploadés et autres ?2021-11-19T11:06:57+01:00Mathieu GiraudChecksum des fichiers uploadés et autres ?Réflexion lancée par @mikael\-sRéflexion lancée par @mikael\-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4627alert : utiliser com.js (et refactorer com.js)2021-01-08T11:42:13+01:00Mathieu Giraudalert : utiliser com.js (et refactorer com.js)
voir aussi #4617 et #4626
voir aussi #4617 et #4626https://gitlab.inria.fr/vidjil/vidjil/-/issues/4324Monitorer le serveur : temps réel + historique2024-01-22T14:22:49+01:00Mathieu GiraudMonitorer le serveur : temps réel + historiqueComplément à #4037, évoqué avec @flothoni et @mikael-s :
- nombre de jobs par jour
- nombre de fichiers uploadés / taille totale
- charge CPU (plus dur ?)
- incidents
éventuellement sur plusieurs serveurs
Graphiques historiques (à...Complément à #4037, évoqué avec @flothoni et @mikael-s :
- nombre de jobs par jour
- nombre de fichiers uploadés / taille totale
- charge CPU (plus dur ?)
- incidents
éventuellement sur plusieurs serveurs
Graphiques historiques (à quel point le lundi est plus chargé ? les congés ?), par curiosité, mais aussi pour nous aider à mieux gérer les incidents.
Via Gitlab ? https://docs.gitlab.com/ee/administration/monitoring/performance/Web 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/4311conf.js: "use_database" : false et notifications2020-06-01T22:38:10+02:00Mathieu Giraudconf.js: "use_database" : false et notificationsJ'ai l'impresion que, même avec `"use_database" : false` dans conf.js, les notifications sont chargées depuis la db. C'est voulu ?J'ai l'impresion que, même avec `"use_database" : false` dans conf.js, les notifications sont chargées depuis la db. C'est voulu ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3211Cas d'usages et tests avant nouvelle feautre2018-04-27T11:01:54+02:00Mathieu GiraudCas d'usages et tests avant nouvelle feautreComment faire pour éviter un nouveau #3199 ? Ce cas est particulièrement intriguant : comment ce bug a pu nous échapper, à 4 testeurs ?
Discussion avec @RyanHerb : pour de telles features, on pourrait lister les cas d'usage... et les re...Comment faire pour éviter un nouveau #3199 ? Ce cas est particulièrement intriguant : comment ce bug a pu nous échapper, à 4 testeurs ?
Discussion avec @RyanHerb : pour de telles features, on pourrait lister les cas d'usage... et les revérifier ensuite. Cela passe bien sûr par des tests (#3201). Normalement c'est bien ce qu'on fait... À surveiller la prochaine fois, notamment pour #3171 :-)https://gitlab.inria.fr/vidjil/vidjil/-/issues/2966Unknown column 'scheduler_task.cronline' in 'field list'2017-12-20T18:04:30+01:00Mathieu GiraudUnknown column 'scheduler_task.cronline' in 'field list'Nous avons eu deux fois en prod l'erreur
```<class 'gluon.contrib.pymysql.err.InternalError'> (1054, u"Unknown column 'scheduler_task.cronline' in 'field list'")```
qui se solutionne par un `ALTER TABLE scheduler_task ADD cronline VA...Nous avons eu deux fois en prod l'erreur
```<class 'gluon.contrib.pymysql.err.InternalError'> (1054, u"Unknown column 'scheduler_task.cronline' in 'field list'")```
qui se solutionne par un `ALTER TABLE scheduler_task ADD cronline VARCHAR(512);`. vdj#534 vdj#589
Est-ce que cela arrive à chaque fois qu'on fait un re-jeu de la db ? Dans d'autres situations ?
Comment l'éviter dans le futur ?
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2956Demander confirmation avant de mettre un patient/run/set en public2017-12-19T09:25:46+01:00Mathieu GiraudDemander confirmation avant de mettre un patient/run/set en publichttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2359Limiter la mémoire allouée aux jobs lancés via les workers2021-11-22T13:51:54+01:00Mathieu GiraudLimiter la mémoire allouée aux jobs lancés via les workersEn complément de #2349, on pourrait limiter la quantité de mémoire par worker ou sur tous les workers. On aimerait ainsi que, même dans des cas non prévus, le serveur réponde toujours même si un process fait n'importe quoi.
Voir http://...En complément de #2349, on pourrait limiter la quantité de mémoire par worker ou sur tous les workers. On aimerait ainsi que, même dans des cas non prévus, le serveur réponde toujours même si un process fait n'importe quoi.
Voir http://coldattic.info/shvedsky/pro/blogs/a-foo-walks-into-a-bar/posts/40, qui discute longuement certaines possibilités.
(On pourrait d'ailleurs avoir une solution non universelle, et par exemple protéger MiXCR par un `ulimit` si cela fonctionne.)https://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/2152Pouvoir signaler sur le client un downtime de la db et/ou la suspendre2018-10-11T10:40:24+02:00Mathieu GiraudPouvoir signaler sur le client un downtime de la db et/ou la suspendreDiscussion originale dans vdj#353.
On veut informer les utilisateurs lors d'un downtime. Cela peut être en automatique (#2151), mais des notifications manuelles peuvent être plus pertinentes.
@magiraud:
> On pourrait peut-être ju...Discussion originale dans vdj#353.
On veut informer les utilisateurs lors d'un downtime. Cela peut être en automatique (#2151), mais des notifications manuelles peuvent être plus pertinentes.
@magiraud:
> On pourrait peut-être juste avoir un fichier `js/alert.js` (*), habituellement vide ou presque, et où on mettrait un message en dur (pas via git) dedans et ce qu'il faut en js/html pour afficher cela.
On pourrait même choisir dans ce fichier de supprimer temporairement l'accès à la db par quelque chose de plus fort que `config.use_db`.
(*) Cela pourrait être aussi dans `js/conf.js`, c'est juste qu'en temps de ~"!!-crisis" on peut avoir des mécanismes simples pour ne pas se planter.
@RyanHerb @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2151Avoir un mécanisme automatique détectant un downtime de la db2017-02-22T17:07:39+01:00Mathieu GiraudAvoir un mécanisme automatique détectant un downtime de la dbDiscussion originale dans vdj#353.
On veut informer les utilisateurs lors d'un downtime. Idéalement on aimerait avoir une notification manuelle (#2152), mais on n'est pas toujours disponible, ne serait-ce que hors des heures de bureau...Discussion originale dans vdj#353.
On veut informer les utilisateurs lors d'un downtime. Idéalement on aimerait avoir une notification manuelle (#2152), mais on n'est pas toujours disponible, ne serait-ce que hors des heures de bureau sur notre fuseau horaire.
@mikael-s :
> Si db.vidjil.org ne répond pas, la notification pourrait apparaître automatiquement. Mais quelle est la définition de « db.vidjil.org ne répond pas » ? Car c'est déjà un peu le rôle du timeout…
> Peut-être un truc qui s'active en utilisant les messages de UptimeRobot ou du monitor Vidjil ?
@magiraud :
> Il peut y avoir un truc automatique disant "down since Xxxx, we will check soon" (éventuellement "More news to come at 9:30am") qui se lance "tout seul" si c'est offline 10/30 minutes de suite...
@RyanHerb