premierlangage
premierlangage copied to clipboard
PremierLangage
[ENHANCEMENT - BUG] Prévoir une procédure quand PL est down
Coucou,
Depuis au moins 10h45 ce matin, PL est down (je crois que c'est la sandbox qui ne va pas...).
Could not join the sandbox 'https://pl-sandbox.u-pem.fr/sandbox/build/'.
J'avoue que je ne sais même pas qui embêter dans ces cas-là.... Cuvelier ? Les devs ? Il faudrait prévoir des mécanismes de relance (non intrusif, juste un bouton pour lancer des reload profonds...) et donner les droits à plusieurs personnes pour assurer une petite maintenance. Pour les devs, les cours sont plus importants que la maintenance applicative ! Il faudrait que la maintenance ne repose pas sur eux...
Il faut voir avec N. Cuvelier, je pense qu'il n'y a encore plus de place... Je pourrais peut être voir ça après 15h45 si il est toujours là.
DR est passé au CRI à 14h, c'était opérationnel en 2 minutes.
J'avais l'air con devant les L3 à 10h45 mais ce n'est pas dérangeant et ça ne change pas de l'habitude. Par contre, il serait intéressant de faire en sorte que ces problèmes ne vous retombent pas dessus (QC, CC, MC). J'avoue être bien désarmé devant ce genre de problème. Ainsi, dans la mesure du possible, il serait pas mal de :
- Tenter d'analyser la source pour éviter que ça se reproduise
- ??? Mettre en place un outil accessible (ou un script) à quelques personnes pour faire du soft reboot
Je trouve bizarre d'être "presque" le seul à constater le problème de 10h45 à 14h00 où j'ai croisé le DR... Pareil pour les élèves, que sont-ils suposer faire quand c'est down ? Peut-être ils n'osent pas se plaindre... On devrait réfléchir à mettre en place un PL-support et inviter à des pratiques saines quand ça ne marche pas. De mon point de vue, se plaindre aux mail de QC, CC, MC ou N.Cuv. n'est pas une pratique saine (sauf si une procédure acceptée de tous le stipule...). C'est pour cela que j'ouvre un ticket et que je rapporte oralement le PB à DR.
Le problème est que personne à part N. Cuvelier n'a accès à la machine pour lancer un script.
Ce serait effectivement bien de mettre en place un système plus pratique, car Christophe et moi ne somme pas disponible 1 semaine sur deux.
j'essaye d'avoir une réunion avec le cri pour la question de la disponibilité ... il faudrait que cela plante moins ...
Historiquement nous avons eu beaucoup de plantage du fait que le top level de python n'est pas réentrant.
mais c'est corrigé depuis longtemps.
Nous avons deux crash inexpliqués qui me font rebooter sur ce besoin. De nouveau "j'essaye" d'avoir une réunion avec le cri pour la question de la disponibilité ...
Sachant qu'à terme, les établissements sont censés partager la charge... Est-ce que l'on ne pourrait pas calquer le modèle des téléchargements lourds (liste de pings sur une whitelist de miroirs puis téléchargement depuis le meilleur miroir).
Pour PLaTon, on pourrait prévoir une whitelist de sandbox (sur plusieurs machines, possiblement dans des universités différentes). Pour chaque suffixe d'adresse mail, on prépare une liste d'affinité : si l'email de l'utilisateur finit par @univ-eiffel.fr alors on utilise
- une machine de Marne (sandbox dernière version)
- une machine de Marne (sandbox ancienne version)
- une machine de Paris-sud
- une machine de l'université de Trifouillit-les-oies
- une machine d'ultra secours
Si une sandbox plante, la liste des affinités "suffixe de mail" --> machines est mise à jour avec un move to back des sandbox plantées, des mails sont envoyé automatiquement lors de la même occasion.
On prépare une liste d'affinité pour les utilisateurs réguliers (@univ-eiffel.fr, @u-psud.fr, ...) et une liste pour le reste du monde (mode démo sans login, nouvelle université sans serveur assets, etc....)
Il faudrait aussi une visualisation publique des stats de chaque machine via une petite URL restfull, chaque sandbox peut dire par jour, pour qui elle grade. C'est un peu de boulot mais ça scale assez bien. Les sandbox étant déjà bien séparées du reste, est-ce tant de travail ?
La liste de sandbox était prévue depuis longtemps. Effectivement une liste de sandbox de secours par site est une bonne idée. Mais avoir une procédure de "reboot" de la sandbox a partir de la zone d'adiministration.
- les sandbox sont dans une table avec uptime, et quelques stats (see NB ;)
- il est possible de modifier l'ordre de préférence
- il est possible d'envoyer un message de reboot et/ou restart, le problème de ce dernier point était que la connection était perdu (cela semblai être un problème de réseau mais pas vraiment .... beurk vivement de debriefing avec le CRI).
C 'est à programmer @qcoumes tu met cela dans tes activités futures. Comment fonctionne la sandbox 2.0 par rapport à ces problématiques ??
C'est @Pavell94000 qui s'occupe de la communication avec la sandbox pour PL 1.0, et c'est effectivement prévue d'avoir plusieurs Sandbox, et une répartition de la charge équitable entre celles-ci.
En ce qui concerne la Sandbox 2.0, à par la possibilité de demander des stats sur les containers (available / running / total), rien de bien différent par rapport à la 1.0. A partir du moment ou le serveur crash pour X raison, il n'y a plus de panneau d'administration, et nous devenons dépendant du CRI.
Réponse du CRI: Je ne comprends pas quel est le problème aux heures ouvrables ? Il me semble qu'aucune remontée n'a été faite par DT pour signaler cette difficulté.
En dehors des heures ouvrables, nous ne sommes comme l'apprenti pas disponibles puisqu'il n'y a pas de garantie de fonctionnement et encore moins de rétablissement.
L'administration des serveurs et des services doit rester une mission exclusive du CRI car les problèmes sont plus larges et plus complexes (avec des incidences possibles sur le reste des infrastructures et SI ) que le redémarrage d'une instance de PL .
Le ssi et les collègues sont maintenant avertis du dysfonctionnement par les différents échanges puisque Nicolas et moi sommes en copie mais il est préférable à l'avenir que les utilisateurs externes ne nous contactent pas directement et que vous centralisiez les remontées afin de les synthétiser puis que vous nous sollicitiez via les canaux habituels.
il nous reste donc a trouver une solution de gestion de la disponibilité.
Si Paris-sud (ou un site autre que Marne-la-Vallée) est le seul à utiliser PLaTon à un instant t et que ça plante, je ne crois pas que le CRI de Marne ait prévu un mécanisme de création de Demande De Travaux pour des gens extérieurs à Marne.
Aussi, la réactivité imposée par notre mission de service publique d'enseignant couplée avec l’émergence d'un jeune projet de recherche et d’innovation pédagogique me parait peu compatible avec les process asynchrones et terriblement lents suivis par les opérateurs du CRI de Marne. Osez l'innovation devant les usagers (nos élèves) à un prix qui notamment contient le fait de rester ultra réactif. Cette mission est pur sûr difficile et, peut-être, atypique pour les opérateurs du CRI de Marne.
Chacun dira que c'est à l'autre de s'adapter et pas à soi... Le risque est que personne ne bouge et que l’innovation prenne fin. (risque réel !!!!)
Soit les deux parties font un geste pour travailler ensemble, soit il faut qu'il y ait séparation. Le CRI doit comprendre que ce projet de grande envergure ne peut pas être totalement testé en pré-production (simuler des centaines d'utilisateurs simultanés avec l’expressivité de l'être humain n'est pas possible). Aussi un système comme les DT est trop long pour assurer la garantie de service que nous devons à nos usagers (surtout quand ils sont 400 et que nous observons couler le bateau durant 4 jours d'affilés...).
De mon ressenti :
- Option 1 --> Se séparer du CRI de Marne et sous traiter la CPU sur un service que plusieurs powers users (issus de plusieurs sites) seront autorisé rebooter. Je juge cette séparation fort triste étant donnée la nature des missions du CRI de Marne et la mission du projet PLaTon.
- Option 2 --> Le CRI valide régulièrement (valide rapidement et possiblement plusieurs à la fois) des scripts de relance de diverses parties de PLaTon. Ces scripts (probablement système) doivent pouvoir être lançable (un clic en interface graphique par exemple...) par plusieurs power-users de PLaTon (issus de plusieurs sites). Ajouter un power-user dans la white list doit aussi être une tâche très rapide (idéalement un power-user doit pouvoir en désigner un autre sans autre forme de ralentissement...).