vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2016-11-29T14:43:10+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/2009CSS/JS manquant pour l'admin de dev.vidjil.org2016-11-29T14:43:10+01:00Vidjil TeamCSS/JS manquant pour l'admin de dev.vidjil.orgL'interface d'admin Web2py ne trouve pas ses CSS et JS : https://dev.vidjil.org/admin/default/site
Est-ce lié au HTTPS ? Si c'est spécifique à rbx (la machine), pas de souci. On va passer dev sur vda de toute façon.
***
Oui c'est le pass...L'interface d'admin Web2py ne trouve pas ses CSS et JS : https://dev.vidjil.org/admin/default/site
Est-ce lié au HTTPS ? Si c'est spécifique à rbx (la machine), pas de souci. On va passer dev sur vda de toute façon.
***
Oui c'est le passage au https qui a cassé le css de l'interface admin
***
Et c'est réparé
***
Merci :)
Pour l'historique, quel était le problème ?
***
la règle 'static' de http que j'ai migrée en https. En fait les css de admin passaient déjà en https et le nouveau routage introduisait une erreur
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2008Redirection de / vers /browser en HTTPS2016-11-29T14:43:09+01:00Vidjil TeamRedirection de / vers /browser en HTTPSEn allant sur https://dev.vidjil.org je ne suis pas redirigé vers le /browser, il faut le rentrer à la main dans l'URL.
***
@RyanHerbEn allant sur https://dev.vidjil.org je ne suis pas redirigé vers le /browser, il faut le rentrer à la main dans l'URL.
***
@RyanHerbhttps://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/2001Configuration de logrotate dans le paquet serveur2024-01-31T13:47:58+01:00Vidjil TeamConfiguration de logrotate dans le paquet serveurLes logs finissent par être gros, logrotate permet de conserver de petits fichiers et de compresser les anciens. (Oui ça doit être pathologique de rentrer une tâche juste avant de prendre l'avion).
***
@RyanHerbLes logs finissent par être gros, logrotate permet de conserver de petits fichiers et de compresser les anciens. (Oui ça doit être pathologique de rentrer une tâche juste avant de prendre l'avion).
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2000Lorsque le run est mal renseigné, ne pas permettre la soumission du formulaire2017-07-05T09:15:55+02:00Vidjil TeamLorsque le run est mal renseigné, ne pas permettre la soumission du formulaireLors de l'ajout d'un fichier, si on ajoute un run qui n'existe pas, il est coloré en rouge mais on peut soumettre le formulaire, ce qui génère ensuite une boite de dialogue disant : « [object Object] error INTERNAL SERVER ERROR », ce qui...Lors de l'ajout d'un fichier, si on ajoute un run qui n'existe pas, il est coloré en rouge mais on peut soumettre le formulaire, ce qui génère ensuite une boite de dialogue disant : « [object Object] error INTERNAL SERVER ERROR », ce qui n'est pas très parlant.
J'imagine que du côté client il y a moyen de contrôler que les champs run et patient sont remplis avec des données correctes.
***
Hotfix prête, déployée sur dev.
Pas encore poussée sur prod-server
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1989Un pre-process en timeout apparaît toujours running2019-02-28T12:40:31+01:00Vidjil TeamUn pre-process en timeout apparaît toujours runningLorsqu'un pre-process est timeout, l'interface web affiche toujours le process comme en cours (avec la petite icone qui tourne). Et on ne peut pas le relancer (mais pour ça cf. #1960 )
***
@nobodyLorsqu'un pre-process est timeout, l'interface web affiche toujours le process comme en cours (avec la petite icone qui tourne). Et on ne peut pas le relancer (mais pour ça cf. #1960 )
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1986Affichage des logs du serveur web2023-06-28T16:37:56+02:00Vidjil TeamAffichage des logs du serveur webDans le panneau d'admin, les logs serveurs peuvent être affichés et c'est le fichier « ../log/nginx/access.log » qui est affiché (ou error.log pour les erreurs). Ce n'est pas très générique puisque cela dépend de l'emplacement des logs V...Dans le panneau d'admin, les logs serveurs peuvent être affichés et c'est le fichier « ../log/nginx/access.log » qui est affiché (ou error.log pour les erreurs). Ce n'est pas très générique puisque cela dépend de l'emplacement des logs Vidjil, des logs du serveur web, du serveur web lui-même et des droits affectés au fichier.
Au passage j'aurais bien ajouté une vérification dans showlog pour que showlog ne montre que les logs de Vidjil (et donc empêche de se balader où on veut dans l'arborescence).
Bref je retirerais bien ces deux liens.
***
@magiraud @RyanHerb @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1970mauvaise récupération des métadonnées sur Demo L42016-11-29T14:42:44+01:00Vidjil Teammauvaise récupération des métadonnées sur Demo L4En faisant la release 2016.08, j'ai testé sur Demo L4 et X5 (cf vdj/doc/vidjil/release.org).
Apparament cela a bien fonctionné (vu les logs, vu les compare patients)...
Mais le lien pour L4, http://rbx.vidjil.org/browser/index.html?pat...En faisant la release 2016.08, j'ai testé sur Demo L4 et X5 (cf vdj/doc/vidjil/release.org).
Apparament cela a bien fonctionné (vu les logs, vu les compare patients)...
Mais le lien pour L4, http://rbx.vidjil.org/browser/index.html?patient=146&config=26 indique, dans son 'info', MiXCR ! De la même manière, celui pour X5 indique un mauvais numéro de version. Est-ce juste l'analysis qui n'est pas le bon ?
***
Peut-être est-ce la même chose que "Lorsque une partie des fichiers est runné, des métadata des mauvais fichiers sont affichés" ?
***
Pour L4, je confirme que c'est juste un problème d'affichage de l'info : les résultats sont corrects et ont bien été obtenus avec Vidjil.
***
Oui, c'est une relique de l'analysis, comme on avait avec le champ log.
J'ai mis en place une hotfix, comme pour le champ log => 09e65aff7f32d79e53 + 7137057aa9030f8a9a00c
La solution est "hacky" mais si on devait faire proprement, ça prendrais beaucoup de temps... On peut en discuter si vous voulez :)
***
Est-ce toujours d'actualité ? La hotfix a été intégrée ?
***
Oui elle est intégrée :)
***
@magiraud @RyanHerb @mikael-s @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1962Erreur la page des logs lorsque connecté en tant que Aurélie2016-11-29T14:42:38+01:00Vidjil TeamErreur la page des logs lorsque connecté en tant que AurélieSe connecter en tant qu'Aurélie, aller sur la page, choisir la table patient… erreur serveur.
***
C'est bon.
***
@RyanHerb @DuezSe connecter en tant qu'Aurélie, aller sur la page, choisir la table patient… erreur serveur.
***
C'est bon.
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1960Relancer un pre-process qui a échoué2017-05-19T14:23:37+02:00Vidjil TeamRelancer un pre-process qui a échouéDans le cas où un pre-process échoue on ne ne peut pas le relancer (alors qu'on peut le faire pour un Vidjil). Pourtant les fichiers sont encore sur le disque et il est donc encore possible de le relancer, il manque juste le bouton en qu...Dans le cas où un pre-process échoue on ne ne peut pas le relancer (alors qu'on peut le faire pour un Vidjil). Pourtant les fichiers sont encore sur le disque et il est donc encore possible de le relancer, il manque juste le bouton en quelque sorte.
***
@DuezRyan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1950Trouver une autre méthode de scheduling, indépendante de web2py2022-06-20T11:59:42+02:00Vidjil TeamTrouver une autre méthode de scheduling, indépendante de web2py(Discuté lors de la Rando 2016)
Un scheduler idéal devrait pouvoir avoir :
1) des priorités fines (petits jobs passent devant gros jobs) (et aussi users Platinium :-)
2) une suspension de tâches
3) une assignation fine de certains (gr...(Discuté lors de la Rando 2016)
Un scheduler idéal devrait pouvoir avoir :
1) des priorités fines (petits jobs passent devant gros jobs) (et aussi users Platinium :-)
2) une suspension de tâches
3) une assignation fine de certains (groupes de) workers à certaines tâches
2) ou 3) permettrait de lancer des choses annexes et rapides (type FineSegmenter ou compare patients ou ...) même si des gros Vidjil (ou autres) tournent
Enfin, penser tout cela dans le cadre d'un "noeud de calcul", possiblement indépendant du serveur web. Le serveur de calcul ne reçoit que des lignes de commande à exécuter et à accès aux fichiers nécessaires par un montage.
Rien d'urgent, à réfléchir posément dans les prochains mois.
***
Task spooler: http://vicerveza.homeunix.net/~viric/soft/ts/ présente les fonctionnalités majeures que nous cherchons (tâches interdépendantes, changement d'ordre dans la file, etc), mais n'a pas d'API pour s'en servir en réseau.
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1948Base de données remplie avec des scheduler_task et scheduler_run2017-07-05T09:15:55+02:00Vidjil TeamBase de données remplie avec des scheduler_task et scheduler_runIl y a une semaine, le 17 juin, il y avait environ 8 000 scheduler_task dans la BD. Aujourd'hui (24/06) il y en a environ 93 000. À raison d'environ 90 000 par semaine la BD risque de s'alourdir rapidement.
À quoi est-ce dû ?
***
Un cert...Il y a une semaine, le 17 juin, il y avait environ 8 000 scheduler_task dans la BD. Aujourd'hui (24/06) il y en a environ 93 000. À raison d'environ 90 000 par semaine la BD risque de s'alourdir rapidement.
À quoi est-ce dû ?
***
Un certain nombre de pre_process... J'imagine que cela vient des pre_process reprogrammés par task.py ?
Au passage, veut-on tout garder les scheduler_task et scheduler_run ? Effacer, au moins pour les pre_process / ou bien au moins pour les vieux trucs ? (on veut les log)
***
Non pas du tout. Ce sont des vidjil. Pour les id > 10000, il y a 82000 vidjil ((db.scheduler_task.id>10000) & (db.scheduler_task.task_name =='vidjil'))
Cela semble etre des vidjil relancés car en attente de la fin du pre-process.
***
ok. Il faudrait donc supprimer ces tâches "vidjil" dans la db, pour qu'il n'y ait que la dernière qui soit enregistrée.
task.py:161, est-ce qu'on pourrait mettre autre chose qu'un "return SUCCESS" et supprimer ces tâches ?
Ou bien utiliser "repeats" + "period" lors du queue_task, et de ne pas relancer de tâche (mais mettre à jour le "repeats" à la bonne valeur quand le vidjil est finalement lancé) ? Ou bien quelque chose avec "retry_failed"
***
Aïe, avec un "repeats", cela créerait quand même plein d'objets scheduler_run...
***
Ça continue encore (probablement les 24 QUEUED qui sont là depuis le problème de Myriam). On a environ 1600 entrées par jour dans scheduler_run qui annoncent « still pending ».
***
J'ai supprimé les runs et les task associés. J'ai backup la bdd avant de faire quoi que ce soit, donc si j'ai fait des bétises on peut revert.
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1946Erreurs serveurs dans les runs2016-11-29T14:42:27+01:00Vidjil TeamErreurs serveurs dans les runsLorsque, sur la page de la liste des runs, on clique sur le nom d'une config pour ouvrir un résultat → erreur serveur
***
Lorsqu'on clique sur un « completed » pour voir le log de Vidjil → erreur serveur
***
Confirmé. Maintenant que les ...Lorsque, sur la page de la liste des runs, on clique sur le nom d'une config pour ouvrir un résultat → erreur serveur
***
Lorsqu'on clique sur un « completed » pour voir le log de Vidjil → erreur serveur
***
Confirmé. Maintenant que les runs sont en prod, cela va vite se voir :-)
***
hotfix poussée: 32d560d2ba3df03876a et b16d5e1be7865bd
J'ai pull sur dev; et fait un petit test: Le pull n'a pas encore été fait sur prod-server (mais le merge, oui)
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1940Lorsque une partie des fichiers est runné, des métadata des mauvais fichiers ...2016-11-29T14:42:23+01:00Vidjil TeamLorsque une partie des fichiers est runné, des métadata des mauvais fichiers sont affichésJ'ai lancé le 2è et le 3è fichier (R2 et fichier mergé) mais les infos affichées (commentaires sur le fichier plus nom des fichiers) sont celles de R1 et R2 : http://rbx.vidjil.org/browser/index.html?sample_set_id=7859&config=34
En reva...J'ai lancé le 2è et le 3è fichier (R2 et fichier mergé) mais les infos affichées (commentaires sur le fichier plus nom des fichiers) sont celles de R1 et R2 : http://rbx.vidjil.org/browser/index.html?sample_set_id=7859&config=34
En revanche les résultats sont bien ceux de R2 et du fichier mergé. C'est donc un problème postérieur au lancement de Vidjil (fuse ou récupération des infos).
***
Ryan, Martin ne t'avait pas parlé d'un bug de ce genre ?
Confirmé par Jona. Ce sont les métadonnées des premiers fichiers qui sont affichés, alors que ce sont les derniers fichiers qui ont été analysés :
http://rbx.vidjil.org/browser/index.html?sample_set_id=3447&config=30
***
Si ! Et Marc l'a corrigé, mais on dirait que ce n'est pas encore dans prod-server.
***
C'est bon, merci.
***
@mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1931Pre-process is still pending, re-schedule2017-07-05T09:15:55+02:00Vidjil TeamPre-process is still pending, re-scheduleToute la nuit, un (des ?) pre-process ont été re-schédulés : cf. la table db.scheduler_run de dev.vidjil.org (https://dev.vidjil.org/vidjil/appadmin/select/db). Donc ça a l'air de tourner en boucle. Ça me semble bloquant avant de mettre ...Toute la nuit, un (des ?) pre-process ont été re-schédulés : cf. la table db.scheduler_run de dev.vidjil.org (https://dev.vidjil.org/vidjil/appadmin/select/db). Donc ça a l'air de tourner en boucle. Ça me semble bloquant avant de mettre cela en prod.
***
Mikaël, tu confirmes qu'il n'y a plus de problème ?
***
apparemment
***
soyons généreux alors, fermons les tâches :-)
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1930Tout ce qui est dans task.py devrait être lancé par un autre utilisateur2022-06-20T18:11:04+02:00Vidjil TeamTout ce qui est dans task.py devrait être lancé par un autre utilisateurDiscussion à l'instant: dans task.py, il peut y avoir des choses méchantes de faites, que ce soit via les configs ou les pre-process.
On pourrait échapper des choses, faire un chroot...
Le plus simple semble de faire tous les lancements...Discussion à l'instant: dans task.py, il peut y avoir des choses méchantes de faites, que ce soit via les configs ou les pre-process.
On pourrait échapper des choses, faire un chroot...
Le plus simple semble de faire tous les lancements par un *autre utilisateur*, qui n'aurait des droits en écriture que sur tmp/. Cela devrait passer tout seul pour vidjil / mixcr (le fichier de résultat étant copié), à voir pour les pre-process.
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1928MiXCR : supprimer les fichiers align.vdjca2016-11-29T14:42:15+01:00Vidjil TeamMiXCR : supprimer les fichiers align.vdjcaAprès avoir lancé MiXCR il faut supprimer les fichiers align.vdjca qui prennent (beaucoup) trop de place.
***
d730289, au doigt mouillé.
***
@RyanHerbAprès avoir lancé MiXCR il faut supprimer les fichiers align.vdjca qui prennent (beaucoup) trop de place.
***
d730289, au doigt mouillé.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1927Sécurité : tout le monde aurait le droit de changer les configs ?2017-01-31T17:37:21+01:00Vidjil TeamSécurité : tout le monde aurait le droit de changer les configs ?En répondant à Shugay, je voulais lui dire de faire un db.call('index/configs') juste pour voir les configs... et, en essayant de mon côté en étant impersonated sur son compte, je me suis rendu compte que je peux *éditer* les configs (al...En répondant à Shugay, je voulais lui dire de faire un db.call('index/configs') juste pour voir les configs... et, en essayant de mon côté en étant impersonated sur son compte, je me suis rendu compte que je peux *éditer* les configs (alors que le droit n'est que de "read" normalement).
***
Ca va meme plus loin, en creusant un peu, je m'apperçois que lancer un db.call avec les bons parametres dans la console affiche la page meme si on n'est pas connecté.
ex: db.call('sample_set/index', {'id' :'62' , 'config_id' : 5 } )
De là, je peux même télécharger le fichier results.
***
J'ai rajouté des vérifications avec la méthode existante dans auth: can_modify_config et j'ai caché les boutons pour les personnes non-admin.
***
Rando 2016: ok pour Ryan. merci !
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1920Retour à l'utilisateur lorsque la requête prend un peu de temps2017-11-24T11:05:20+01:00Vidjil TeamRetour à l'utilisateur lorsque la requête prend un peu de tempsÀ partir de quelques dixièmes de seconde, afficher « Loading » en haut de la page, puis au bout de une seconde « Still loading » avec un fond un peu plus voyant. Cela ne changera rien aux timeouts, mais cela devrait éviter que les utilis...À partir de quelques dixièmes de seconde, afficher « Loading » en haut de la page, puis au bout de une seconde « Still loading » avec un fond un peu plus voyant. Cela ne changera rien aux timeouts, mais cela devrait éviter que les utilisateurs appuient de nombreuses fois sur le bouton (en pensant que la requête n'a pas été prise en compte), surchargeant encore plus le serveur.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1912Browser help : 4042016-11-29T14:42:04+01:00Vidjil TeamBrowser help : 404http://rbx.vidjil.org/browser/help
***
Disparu à cause de la scission entre prod-server et prod-browser
***
@magiraud @mikael-shttp://rbx.vidjil.org/browser/help
***
Disparu à cause de la scission entre prod-server et prod-browser
***
@magiraud @mikael-s