[WCG] World Community Grid (multi-projets)

[fzs600]

Ha non pas encore  y a des petits  qui traînent dans le hall. 

[modesti]

3.5" Madame, 3.5"

Oups, au temps pour moi. J'ai dû confondre avec le format des disquettes du traitement de texte Amstrad

[JeromeC]

18 octobre 2025

• Nous envoyons dès ce soir de petits lots d'unités de travail avec des identifiants de lot compris entre 9999900+ pour MCM1 afin de tester les nouveaux démons create_work spécifiques à l'application, qui permettent la mise à jour et la création de lots distribués tenant compte des partitions. Les quelques volontaires qui recevront ces unités de travail avant que nous commencions à publier des lots plus importants, lorsque nous serons certains que le nouveau système fonctionne comme prévu, remarqueront peut-être que ces unités de travail comportent un nombre de signatures beaucoup plus faible et s'exécutent beaucoup plus rapidement que la normale. Il s'agit toujours d'unités de travail significatives, mais les paramètres clés tels que le nombre de signatures à tester par unité de travail ont été réduits afin que nous puissions obtenir rapidement des commentaires.


• Comme pour ARP1, nous avons transféré tous les modèles et la préparation des unités de travail vers les serveurs WCG pour MCM1. Nous l'avions déjà fait pour la version bêta de MAM1 (beta30), mais nous avons pu transférer le rendu des modèles d'unités de travail par lot directement dans le code C++ du démon create_work, où il utilise un schéma protobuf provenant du registre de schémas de Kafka/Redpanda, qu'il hydrate ensuite pour produire toutes les unités de travail du lot selon les paramètres souhaités qu'il utilise à partir du sujet « plan » via Kafka. D'où le terme « spécifique à l'application » ci-dessus. Ensuite, il met à jour la base de données BOINC en bloc au lieu d'appeler la fonction create_work() de BOINC. Les métadonnées sont locales, partitionnées, répliquées dans Kafka pour plus de durabilité, chaque lot écrit des fichiers dans 1/6e des compartiments de ce nœud à partir du répertoire fanout dir_hier de BOINC et valide 1/6e des enregistrements du lot dans la base de données dans des plages non superposées par 10 000 unités de travail par lot.


• Les nouveaux validateurs fonctionnent et sont déployés. Dans notre nouvelle approche distribuée et partitionnée, les validateurs traitent UNIQUEMENT les unités de travail locales à leur hôte, les téléchargements sont partitionnés selon le répertoire de diffusion attribué par BOINC, acheminés vers le nœud backend correct par HAProxy correspondant aux compartiments de diffusion BOINC. Nous répartissons les compartiments entre les nœuds, au lieu de les utiliser pour les répartir sur le système de fichiers et éviter un nombre massif de fichiers dans un seul chemin de téléchargement BOINC. Nous les répartissons sur le cluster et lisons/écrivons ces compartiments dans tmpfs afin qu'Apache serve les téléchargements et accepte les téléchargements en mémoire, que les validateurs lisent en mémoire, Kafka/Redpanda obtiennent une copie des téléchargements dans un sujet répliqué et persistant sur le disque pour plus de durabilité. Ainsi, si un nœud tombe en panne et que nous perdons le cache en mémoire des téléchargements et des chargements, nous pouvons les rejouer et les récupérer.


• En s'abonnant à un sujet Kafka contenant le nombre de téléchargements, une réduction des événements de téléchargement émis vers les sujets Kafka à partir des nouveaux file_upload_handlers uniquement pour les compartiments locaux de cette partition, les emplacements de fichiers appartenant à une paire d'unités de travail, et émet la réussite ou l'échec vers une autre file d'attente pour « assimilation » en aval. Nous avons écrit et testons actuellement un applicateur par lots qui collecte les événements de validation réussis sur chaque partition et met à jour par lots la base de données BOINC afin que le transitionneur et le planificateur puissent travailler ensemble pour évaluer l'état de ces unités de travail. Une fois que nous sommes certains que les mises à jour par lots fonctionnent comme prévu depuis l'applicateur, les utilisateurs devraient commencer à voir les unités de travail en attente de validation passer à l'état « valide ».


• Nous n'utilisons pas file_deleter ni db_purge pour le moment, car ils doivent être repensés pour s'adapter à la nouvelle configuration, ou au minimum évalués pour s'assurer qu'il est judicieux de les lancer sans modification. Nous ne craignons pas pour l'instant de manquer d'espace dans la base de données ou sur le disque, mais seulement de commettre des erreurs. Nous évaluerons donc bientôt, mais pas maintenant, si des modifications doivent être apportées à file_deleter et db_purge. Il est probable qu'ils exploiteront également les données d'événements par unité de travail provenant de Redpanda/Kafka au lieu de se contenter de communiquer avec la base de données BOINC et d'opérer sur des partitions locales à travers le cluster. Mais comme nous produisons des événements pour le cycle de vie complet de chaque unité de travail vers les sujets Kafka, nous disposons d'un niveau de visibilité et de contrôle que nous n'avons jamais pu atteindre avec l'ancien système, et nous avons pu configurer prometheus node_exporter, exploiter les points de terminaison des statistiques Docker par nœud à travers le cluster, et de même pour Redpanda/ Kafka avec l'aide du dépôt https://github.com/redpanda-data/observability afin de mettre en place un tableau de bord Grafana qui nous permettra de faire beaucoup de choses, comme afficher les pages d'état du serveur et améliorer les pages de statistiques.

21 octobre 2025

• Enfin, des tests de résistance plutôt que des tests de conformité.


• Envoi d'un lot de 100 000 unités de travail (exécution rapide, taille réduite au cas où quelque chose planterait).


• Merci pour votre patience et votre soutien continu.

[modesti]

Le résumé en trois lignes me va très bien

Et sinon, en allant dans mon compte, vu l'arrivée de l'appli Mapping Arthritis Markers (MAP).
En revanche, malgré mon choix de faire du bêta et la demande de m'inscrire aux nouvelles applis lorsqu'elles arrivent, ben, l'appli n'était pas cochée. Peut-être parce que j'avais décoché MCM ?

[JeromeC]

De toutes façons vu les monstres qui ont toujours fait (et referont) du WCG c'est pas 100k tâches qui vont nourrir leur homme...

[[CSF] Christian Carquillat]

J'ai peu fermé les vannes sur Asteroids, ça me prend du MCM
Jusqu'au choix du prochain sprint (avant ou après ma nuit, bonne question)

[JeromeC]

Ni avant ni après, c'est à minuit

[JeromeC]

24 octobre 2025

• Nous avons suspendu les téléchargements et la publication des lots de test pendant que nous travaillons sur le problème de débit de validation.


• Nous pensons avoir identifié la cause principale du faible taux de validation des lots de test MCM1, et nous enverrons quelques lots de test supplémentaires pour confirmer que la correction fonctionne.


• Si cette correction est définitive et que nous constatons le taux de validation attendu pour les paires de téléchargements MCM1 pour les nouveaux lots, nous réutiliserons le consommateur Kafka sur les événements de téléchargement déclenchés pour les lots de test reçus plus tôt dans la semaine, ce qui devrait permettre au nouvel assimilateur de lots de traiter ces validations et d'attribuer des crédits de manière idempotente.


• Si tout se passe bien, nous programmerons la reprise des lots MCM1 réguliers à la place des lots de test.


• Comme l'ont fait remarquer les bénévoles, nous n'avons pas encore réconcilié les téléchargements des résultats MCM1 réguliers soumis avant que nous commencions à envoyer les lots de test et avant la migration, mais nous disposons de ces fichiers et nous pourrons le faire dans le cadre d'une mise à jour par lots une fois que le chemin d'accès aux nouvelles unités de travail fonctionnera comme décrit ci-dessus.


• Naturellement, nous ne reprendrons l'ARP et le MAM qu'une fois ces problèmes entièrement résolus.

28 octobre 2025

• Nous avons corrigé les principaux problèmes de débit de validation avec le nouveau flux de travail basé sur Kafka et avons retraité les téléchargements effectués à partir du moment où nous avons commencé à envoyer des lots de test. Nous examinons actuellement les sujets Kafka et la base de données BOINC afin de déterminer si les rapports des bénévoles concernant les résultats d'une unité de travail test téléchargée mais non validée/assimilée lors du retraitement constituent un autre bug à corriger et, le cas échéant, si celui-ci est suffisamment grave pour bloquer la distribution régulière des lots MCM1_024% jusqu'à sa résolution.


• En examinant la mise en œuvre du transitioner (que nous avions l'intention de lancer hier pour commencer à déclencher les renvois des lots de test), nous avons constaté que le nouveau paradigme de stockage des détails de configuration nécessaires pour remplir les renvois dans le tableau des résultats devait être intégré dans les fonctions clés. Nous testons actuellement ces modifications relativement mineures du transitioner.


• Notre plan consiste à déployer le transitioner mis à jour, à vérifier que les renvois fonctionnent, à vérifier qu'il expire les unités de travail expirées, et en fonction de cela et de l'examen des « validations manquées » mentionnées ci-dessus, nous pourrions alors être prêts à reprendre les lots MCM1 dans la fourchette normale.


• En ce qui concerne les téléchargements qui couvrent la période d'indisponibilité pour la migration, nous procéderons à la validation et à l'attribution des crédits pour ces unités de travail dès que le chemin de production pour MCM1 décrit ci-dessus sera opérationnel.


• Nous devrions pouvoir utiliser les nouveaux composants pour ce faire, après avoir parcouru les systèmes de fichiers où se trouvent ces téléchargements, vérifié la liste qui doit être validée et créditée dans la base de données, et suivi un chemin de « retraitement » similaire qui a bien fonctionné pour réessayer la validation et le crédit des lots MCM1 de test.


• Ensuite, nous commencerons à tester beta30/MAM1 et ARP1 à l'aide du nouveau système, ce qui devrait progresser beaucoup plus rapidement maintenant que nous avons mis au point la logique avec MCM1.


• Les mises à jour des stats reprendront dès que le flux de travail MCM1 sera stable, ce qui inclura l'exportation quotidienne vers https://download.worldcommunitygrid.org/boinc/stats/

Je crois que j'ai enfin tout compris : en fait ils font des test, afin de préparer des tests, comme ça quand ils ont fini leurs tests, ils peuvent passer aux tests, et comme ça, dès que les tests sont prêts, hop on peut commencer les tests. 

Ca me rappelle un film : neverending stoooryyyyyy...

[[CSF] Christian Carquillat]

Et t'as même pas parlé des tests en cours qui attestent des tests qu'on déteste, c'est bâclé comme réponse 
Tu peux pas test 

[JeromeC]

Je teste si je veux !!