Tous les articles par Philippe Gauron

Réunion du 28 mars 2019

  • Avec le télétravail, les réunions présentielles sont concentrées mardi & jeudi, il y a donc moins de participants aux réunions dev@lal
  • 4 items proposés à titre indicatif:
    • Make, utilisé par Antoine à l’ordre 0 comme aide-mémoire (la 1ere cible s’appelle help => cibles), utilisé par François aussi pour de la compilation, utilisé par Julius & Julien pour LaTeX et Antoine pour PDFs, par Julius pour beaucoup de choses
    • Versioning en Python: Depuis longtemps, Antoine utilise un paquet (boomversion ?) pour générer ses numéros de version en Python et s’assurer qu’ils soient cohérents à travers le paquet, mais pas sûr de bien le gérer. En python il y a __version__. (En C il y a des techniques à base de define + hash VCS)
    • Antoine a récemment essayé gitlab CI dans SVOM. A essayé docker compose, mais n’avait pas d’image à jour. Donc il s’agit de générer du docker dans docker… Il peut en parler dans un contexte Gitlab au CC.
    • PSPA: François a plein de choses à dire. Des déboires ont eu lieu avec la sous-traitance avec l’entreprise CGI, mais ça a été bien rattrapé et la fin approche. Le résultat s’annonce plutôt satisfaisant pour Antoine.
  • Grande nouvelle: La prochaine version de mercurial sera en Python 3

PSPA

  • Il y a une partie visualisation d’objets physiques dans PSPA, et CGI avait compris ça comme une visualisation graphique figée. Il s’agissait en fait de visualiser une machine complète avec des éléments interactifs. Cela a mené à une sous-estimation de l’effort par CGI, et donné lieu à un résultat catastrophique assez éloignée des besoins. Ils ont rattrapé le coup en mettant un très bon développeur qui a bien rattrapé le développement en 6 mois. Le LAL a cependant dû prendre certains bouts en charge, comme le contrôleur.
  • Maintenant on visualise la machine, on lance les exécutions, on voit la sortie. C’est au LAL d’analyser les résultats, faire des courbes… ce ne sera pas fait par CGI. Comme le code est propre, bien architecturé, avec un découplage frontend/backend en flask, ce sera faisable…
  • Grigory: Finalement, est-ce que ça valait le coup de sous-traiter plutôt que d’embaucher en interne?
    • l’expérience est formatrice pour l’équipe, et a permis un transfert de compétences intéressant
    • ça a coûté autour de 32k euros, incluant une analyse ergonomique assez longue avec les gens du DepAcc
    • Christian : remarque que la manipulation d’objets interactive ça existait déjà dans Pinball Construction Set sur l’Apple II
    • Maintenant, SVOM se lance dans Vue.js
    • Grigory se demande si ça servira d’exemple au CNRS pour externaliser le reste de l’informatique plus tard ?
    • Antoine : un poste permanent était impossible à obtenir, et un CDD de prix comparable avait peu de chances de réunir toutes ces compétences et vouloir travailler au CNRS
  • Christian : l’externalisation force à exprimer correctement son besoin (Antoine: les ateliers sur l’ergonomie aussi)
    • Pas facile de concilier les besoins du DepAcc, ou même de les faire exprimer.

Makefile

  • Les expériences HEP utilisent des systèmes d’exploitation très anciens, donc ils doivent recompiler des versions plus récentes de toute la pile applicative (compilateurs, bibliothèque…) par-dessus. On parle d’externals.
    • Souvent, c’est fait avec d’immenses makefiles, soit directement (cas de Belle 2) soit via une génération intermédiaire par CMake (cas de LCG)
    • Hadrien a dû activer les infos de déboguage dans les externals Belle 2, car c’est aujourd’hui nécessaire pour le profilage de code et en analyser les goulets d’étranglement
      • La faute à l’optimisation -fomit-frame-pointer, aujourd’hui activée par défaut .
    • Mauvaise idée d’activer les infos de déboguage partout, car c’est très coûteux sur certains paquets (ex: clang prend 2x plus de temps à compiler et pèse plusieurs Go en plus)
    • Il a fallu utiliser un hack horrible impliquant l’évaluation paresseuse de variables, la variable automatique $@ et le pattern-matching
    • Conclusion: Make est-il le bon outil?
    • Approches courantes: générer des makefiles (CMake, Meson…) ou plus rarement remplacer entièrement l’outil (Scons…)
    • Permet de simplifier et optimiser l’outil make puisqu’il n’est plus destiné à être directement utilisable par des humains (cf Ninja, tup…)

Adresses électroniques

  • un WP a réfléchi sur le changement de nom du futur laboratoire et ses conséquences au quotidien : nouvelles addresses électronique, etc… Antoine Petit a aussi récemment proposé pour la visibilité du CNRS que tous les salariés CNRS  ait une adresse en cnrs.fr
    • Implique un changement de politique dans la gestion du courrier électronique (serveur commun, même pour une simple redirection)
    • Casserait beaucoup de services qui utilisent l’adresse électronique comme identifiant.
    • Officiellement, ça se produirait en septembre
    • Problèmes: doublons à gérer (Christian a rencontré des soucis lors de la transition Labintel -> Reseda dans Atrium)
    • Globalement, les noms sont des identifiants pourris…
    • Problèmes avec l’UTF-8

Consommation d’énergie des langages

  • un article est sorti récemment sur le sujet.
    • L’analyse assez critiquable car elle ne prend en compte que la phase d’exécution et pas la phase de compilation, et les machines virtuelles n’ont jamais vraiment été adaptées à cet usage
    • Un compilateur JIT (just in time, qui compile par partie lorsqu’une partie est demandée, et pas tout d’un coup) et un ramasse-miettes font aussi du travail à l’exécution. On compare donc un travail d’exécution pour certains langages, et de compilation+exécution pour d’autres langages (utilisant une compilation JIT)
    • En terme de perfs d’exécution, on peut faire à peu près aussi bien que C++ avec une VM, cf. Sing#/Midori, Unity DOTS
    • Ce serait plus juste de chercher des implems Java optimisées pour la conso d’énergie. Il y a longtemps, on utilisait du java sur téléphone (J2ME), aujourd’hui la machine virtuelle Dalvik transformant le bytecode Java sous android pourrait aussi être testée.

Intégration continue

Réunion du 17 janvier 2019

Cours d’informatique de NPAC

Le cours d’informatique de NPAC redémarre bientôt.

Pour rappel, il s’agit principalement de pratiquer les outils de devéloppement : Git, les forges, et quelques bonnes pratiques… L’accent est mis sur la qualité du code.

L’équipe principale est composée de 4 membres du SI. Par exemple, Christian y consacre au moins la moitié de son temps.

GSoC est de retour

Cet événément, initié par Google en 2005, encourage des étudiants à contribuer à de l’open-source (https://google.github.io/gsocguides/mentor/).

HSF y participe en tant qu’ombrelle, qui rassemble des institutions et des projets logiciels (ROOT, ACTS…). Chaque projet propose des contributions aux étudiants, qui ont également la possibilité de faire des propositions de contributions au projet.

Une phase de sélection se déroule pour retenir des candidats pour chaque projet, ceux retenus par Google sont financés, relativement bien, selon leur pays de résidence (~2k € net en France). Ensuite, l’encadrement se fait à distance par des mentors proposés par chaque projet hôte.

Antoine, qui contribue à l’organisation de l’ombrelle HSF, fait de la pub sur RI3 et a présenté le fonctionnement du projet.

29 étudiants ont choisi un projet HSF en 2018, parmi lesquels 26 sont allés jusqu’au bout. Sébastien Binet a fait pas mal de propositions, notamment autour de Go.

A la fin du programme, les mentors gagnent un t-shirt GSoC.

L’encadrement de Google est défini par certaines règles de vie édictées dans un règlement et vérifiées par quelques évaluations, mais globalement ce sont les mentors qui font l’encadrement.

Quelques retours du LAL

  • Hadrien : une charge de travail énorme, et 3 mois à distance c’est court (communication peu efficace).
  • Christian et Julien : effectivement beaucoup de charge, mais ça a donné lieu à de belles contributions à Spark3D. Des réunions quotidiennes étaient organisées. La contribution continue pour l’excellent participant de Christian et Julien, qui a trouvé un travail et continue de participer

SVOM

La semaine prochaine, le CNES réceptionnera le projet SVOM. Après une période de sommeil de quelques années, les participants en sont sortis motivés, ce qui permet à l’équipe d’être efficace malgré/avec un encadrement original.

Serge a approfondi l’usage de kubernetes, docker, swarm, les secrets. L’apprentissage se fait en groupe.

L’essentiel des échanges autour de SVOM se fait par le chat persistent Slack. Cet outil est aussi utilisé pour Astrolab.

Serge propose de faire un retour informel et local sur SVOM quand il aura plus d’expérience (en juin? ça fera 1 an)

Gestion du flux des communications

Comment gérer le flux intense des courriers électroniques ?

Il est important de faire fréquemment un pré-tri pour jeter l’inutile en gardant de côté les messages intéressants. Ce pré-tri doit être fait tous les jours, là où la vraie lecture peut attendre 1-2 semaines.

Un FLOT a aussi été lancé en 2016 sur la question de l’archivage numérique : https://www.fun-mooc.fr/courses/Paris10/10003S02/session02/.

Une autre possibilité est d’éviter l’utilisation du courrier électronique dans des domaines où ce support est inapproprié, comme les échanges rapides. Les chats proposent un système de canaux permettant de séparer différents sujets de discussion, Zulip étant sans doute le moteur qui a poussé le concept le plus loin.

Comme alternative aux chats propriétaires comme Slack, il est possible d’utiliser une instance auto-hébergée du clone libre Mattermost. Celui-ci est installé au CERN ainsi que chez Framasoft. Son installation au CC a déjà été discutée, elle est envisageable si il y a de la demande.

En-dehors de la communication entre humains, les chats simplifient aussi l’utilisation de robots qui diffusent des nouvelles (ex: statut de l’intégration continue) et acceptent des commandes des utilisateurs du chat pour déclencher certaines actions.

PSPA

Après des débuts difficiles, le projet PSPA est maintenant sur les rails.

Le prestataire CGI avait initialement mal compris les conseils, choix technologiques et besoins du LAL. Mais depuis septembre, l’entreprise a corrigé le tir, et la phase de test commence officiellement au moment même de la réunion!

Demi-journée intégration continue de LoOPS

LoOPS a récemment organisé une session d’une demi-journée à l’Inria sur le thème de l’intégration continue. David et Philippe y ont assisté.

Des exemples C++, Java, et Python étaient fournis pour servir de support, chacun choisissant le langage qui lui convient. Il était aussi possible d’utiliser son propre code, ainsi David a choisi d’effectuer ses tests autour de NPAC.

Au début, on met en place des jeux d’essais, puis des sujets plus poussés sont introduits autour de Docker. La formation se faisait sur Gitlab CI à partir d’un didacticiel initialement créé sur Jenkins.

Antoine a aussi mis en place une CI dans SVOM.

L’option « Auto DevOps », qui avait fait beaucoup parler d’elle il y a quelques temps, n’a pas été présenté et reste mystérieuse… Elle est sensée configurer l’intégration continue automatiquement, mais est plutôt pensée pour des logiciels déjà matures. Mais fonctionne-t-elle aussi bien de partir des gitlab.yml fournis par Gitlab que de ceux des autres projets qu’on connaît ?

Divers

Le projet Coding Pool (gestionnaire de tutoriels écrit par Cyril) est en sommeil, mais une démo est dispo sur https://codingpool.in2p3.fr/.

Olivier du LPGP se présente de nouveau à ceux qui n’étaient pas là la dernière fois. Il travaille sur LaserX, où il fait des interfaces en C++/Qt ainsi que de la synchro (alim HT et éléments pulsés) avec de la programmation FPGA en VHDL.

Réunion du 22 novembre 2018

GraphDB dans ATLAS

Julius a fait une présentation sur l’utilisation d’une base de données pour graphes dans ATLAS. Il a réutilisé des planches existantes, mais en passant plus rapidement sur les parties qui ne sont intéressantes que pour ATLAS.

Le terme « GraphDB » peut être compris de plusieurs manières :

  • Le concept général d’une base de données pensée pour stocker des graphes (noeuds reliés par des relations non connues à l’avance)
  • Une implémentation commerciale de ce concept par l’entreprise Ontotext
  • Une autre implémentation de ce concept, dans le contexte de l’ATLAS Event Index, sur laquelle Julius travaille

Ici, nous parlerons principalement de l’implémentation ATLAS. Mais Julius souhaiterait changer le nom du projet ultérieurement, afin d’éviter toute confusion.

L’ATLAS Event Index est un catalogue interactif de métadonnées d’événements de physique des particules. Il permet aux physiciens d’ATLAS de chercher des événements vérifiant certaines propriétés pour leurs analyses, via une interface web.

Certaines métadonnées expriment des relations entre événements, ou bien d’un événement à d’autres entités. Ces relations constituent un graphe au sens de la théorie des graphes. Mais elles sont difficiles à exprimer dans le vocabulaire des bases de données relationnelles classiques, notamment quand on veut pouvoir facilement ajouter ou supprimer des relations au sein de la table.

Les bases de données pour graphes visent à résoudre ce problème. Elles s’appuient généralement sur une base de donnée relationnelle, qu’elles utilisent d’une certaine manière pour introduire le concept de relation entre noeuds au sens de la théorie des graphes. L’API qu’elles proposent est plus simple à utiliser dans ce cadre, au prix toutefois d’une performance plus chaotique qu’avec l’utilisation directe du SQL. On pourrait ici faire un parallèle avec la différence entre le Fortran et les langages orientés objets : l’un est plus facilement optimisable par le compilateur, l’autre plus flexible.

Il n’y a pas de moteur de base de données dédié aux graphes, sans doute parce que les modèles de données sont finalement assez simples (une poignée de tables) et la pertinence d’un système dédié est donc contestable. En revanche, il est assez facile de changer de moteur de base de données, par exemple Julius a déjà fait une migration HBase => Cassandra sans problème majeur.

Le concept de base de données pour graphe est ancien, mais a connu un regain d’intérêt récemment, car il facilite le stockage d’un réseau de neurones au sein d’une base de données avec possibilité de modifier la topologie dudit réseau ultérieurement.

Au fil de son histoire, l’ATLAS Event Index a utilisé de nombreux back-ends pour stocker ses métadonnées :

  • Au début, il y avait une base de données Oracle, mais cela s’est révélé trop inflexible.
  • Ensuite, le projet est passé à un stockage Hadoop, plus flexible mais dont la latence s’est révélée trop mauvaise pour une utilisation interactive depuis l’interface web.
  • Puis il y a eu une migration partielle à HBase, où le projet s’est retrouvé à essayer d’implémenter lui-même une base de données de graphes par dessus un système relationnel. Le système résultant s’est avéré complexe et difficile à maintenir.
  • C’est la raison pour laquelle l’Event Index se dirige maintenant vers une base de données directement pensée pour le stockage de graphes.

Julius a fait un petit tour d’horizon des possibilités actuelles de l’interface graphique de l’ATLAS Event Index en terme d’affichage et d’interaction avec des graphes stockés dans HBase. Bien que l’interface soit implémentée en Javascript, elle est capable de supporter des volumes de données très importants.

Dans le cadre du projet GraphDB, un des objectifs poursuivis est de rendre la couche d’interface graphique moins spécifique à l’Event Index, d’utiliser un système plus générique pour l’affichage de graphes qui tire parti de l’information « graphe » de haut niveau exposée par la nouvelle base de données.

Cette information est exposée sous la forme d’une API fonctionnelle appelée Gremlin, standard de fait qui a été interfacé dans toutes sortes de langages de programmation. Julius a utilisé l’implémentation JanusGraph de cette API, qui introduit la notion de graphe par dessus un stockage existant (ici HBase) et permet de manipuler les données soit comme un graphe, soit via une interface relationnelle à la SQL. Il existe d’autres implémentations de Gremlin, par exemple neo4j est aussi actuellement étudiée au sein d’ATLAS.

Des outils génériques de visualisation de graphes basés sur Gremlin existent. Malheureusement, les outils généralistes et open-source disponibles n’étaient pas très convaincants. Julius a donc décidé d’écrire le sien, en gardant à l’esprit que l’idée est d’être applicable à tout type de graphe (pas seulement ceux de l’Event Index).

La pile technologique actuelle utilise Groovy pour parler à l’API Gremlin du côté du serveur, et Javascript du côté de l’interface web du client. Les transparents contiennent quelques exemples de requêtes Gremlin qui donnent une idée de ce qui est faisable et du mode de fonctionnement de l’API. Il est possible d’interagir avec Gremlin soit via une API web, soit via un client en ligne de commande.

Le passage à l’échelle de GraphDB est assuré par l’utilisation de Hadoop et HBase, donc Julius s’attend à avoir des performances comparables à la solution existantes.

Guy a demandé si une extension aux données d’événements (au-delà des seules métadonnées, donc incluant des informations comme des points de mesure ou des traces de particules) serait envisageable. Julius pense que le système actuel n’a pas été conçu pour gérer ce volume de données beaucoup plus important (~Po, contre ~10s de To actuellement) et aurait des difficultés à le faire. De plus, même en supposant que la chose soit faisable sur le plan technique, l’idée serait très probablement rejetée sur le plan politique.

Guy se demande aussi s’il serait possible d’extraire des données de fichiers de graphes locaux, par exemple utilisant le format DOT de GraphViz. Julius explique que le cas d’utilisation principal d’une base de données pour graphes reste d’aller chercher dans un serveur de bases de données, mais qu’il existe un backend permettant d’accéder à des données en RAM qui pourrait peut-être servir dans ce genre de cas.

Julien s’est interrogé sur le nombre d’utilisateurs simultanés que pourrait gérer l’Event Index, invoquant le compromis entre efficacité maximale (système de batch centralisé) et passage à l’échelle maximal (base de données distribuée). Pour l’instant, le système utilise HBase, une base de données distribuée.

Formation Git

Hadrien termine l’évolution du support de sa formation Git qui se déroule la semaine prochaine.
Le support est disponible ici

Il a essayé Git LFS pour l’occasion, qui est peut-être un peu désagréable à installer, mais très transparent ensuite.
Grigory souligne qu’il faut prévenir  dans la doc d’un dépôt quand on l’utilise.
François se demande s’il y a réellement besoin d’une formation pour utiliser git, puisqu’il suffit de 5 commandes. Il est possible qu’un Antoine soit nécessaire pour compléter les 5 commandes…
S’ensuivent des discussions sur les intérêts respectifs des didacticiels (« tutorials » en anglais) par rapport à la doc de référence de git.

Christian indique que les outils graphiques comme SourceTree aident à l’apprentissage en illustrant et montrant les commandes
GitHub et GitLab montrent aussi de plus en plus des commandes à exécuter

Le passage à l’échelle nationale de cette formation git est envisagé, via une mise à disposition pour DevLog.

Réunion du 11 octobre 2018

JIs 2018 à Port-Bail

Cette année, il n’y avait pas de sessions parallèles pour développeurs et administrateurs, mais une série de sessions plénières.

Au niveau des avantages, on peut mentionner la mise en contact de ces deux communautés qui se parlent peu et la plus grande visibilité de sujets transverses (packaging, conteneurs, middleware de la Grille). Au niveau des inconvénients, les devs trouvent qu’il y a trop de sujets ASR et vice versa.

Un exposé de la direction IN2P3, présentant les résultats des groupes de travail sur les compétences des informaticiens, a fait polémique. En effet, la classification proposée ne satisfaisait pas tout le monde, et l’objectif poursuivi n’était pas clair. Il semblerait que ces études pourraient affecter le recrutement (en informant des décisions sur les compétences prioritaires à rechercher, ou à l’inverse sur les compétences non prioritaires que l’on peut mettre de côté), et que l’un des buts poursuivis par l’IN2P3 soit d’avoir plus de visibilité sur les compétences présentes pour aider le pilotage.

Un autre exposé intéressant concernait les bandes magnétiques. La fin de celles-ci n’est pas pour demain, mais l’un des deux constructeurs de lecteurs de bande a arrêté cette activité, et celui qui reste est donc désormais en situation de monopole. Ceci place le CCIN2P3 en situation très délicate, étant donné qu’ils ont un grand parc de lecteurs du fabricant qui vient de cesser la production…

L’organisation des ateliers (tutoriels, piscines…) était assez décevante, mais les ateliers en eux-même étaient plutôt satisfaisants.

L’organisation des prochaines journées informatiques sera probablement effectuée par le LAL, qui envisage de les situer à proximité de la vallée d’Orsay. La difficulté est de trouver un lieu qui puisse héberger pour 4 jours à 110€/personne tout compris dans la région. Certains sont déçus par le choix peu attrayant de l’Île de France, mais il faut toutefois rappeler que les soutiens financiers du RI3 ne sont pas forcément disposés à se rendre dans des lieux trop reculés…

Journée LoOPS – conda

Antoine & David sont allés à la journée LoOPS sur conda (`9 octobre 2018 – Journée conda – LoOPS <https://reseau-loops.github.io/journee_2018_10_Conda.html>`_)
Les diapos et les TP sont dispo en ligne (`gouarin/conda_tutorial <https://github.com/gouarin/conda_tutorial>`_). Un article a aussi été écrit sur le projet mené par plusieurs membres de la communauté LoOPS (`article sur les paquets conda <https://medium.com/@lgouarin/conda-smithy-an-easy-way-to-build-and-deploy-your-conda-packages-12216058648f>`_).

La journée se déroulait dans un bel amphi, dans un beau bâtiment (Inria Saclay « Turing »), avec des prises sur chaque siège, c’est notable et pratique.

Les discussions ont porté sur Anaconda, conda, et miniconda.

  • Anaconda est une grosse distribution Python (~2 Go) ;
  • conda est le gestionnaire de paquet utilisé par cette distribution ;
  • miniconda est une distribution minimaliste basée sur conda (~240 Mo avec « seulement » 34 paquets installés).

Il est préférable d’utiliser miniconda qu’Anaconda, car chaque environnement virtuel d’Anaconda hérite de l’environnement de la distribution (et donc de tous les paquets python de celle-ci) et de tout l’environnement système
Cette problématique est plus générale aux environnements système, et existe donc aussi avec d’autres gestionnaires de paquets comme Brew. Tous les gestionnaires de paquets ne se préoccupent pas autant de cette question.
miniconda est idéal pour des images docker minimalistes

Durant la journée, le système de paquetage conda a été présenté, il concerne des langages de programmation au delà de Python.
Anaconda et conda sont gérés par l’entreprise Continuum, sous une licence soit libre. Le dépôt de paquets reste cependant géré par Continuum. La question du risque de changement de gestion par Continuum a été posée, la communauté semble se considérer suffisamment organisée pour y palier le cas échéant. Un problème (de bien plus forte ampleur) s’est cependant posé avec npm il y a quelques années quand une partie importante des sites mondiaux avait cessé de fonctionné durant plusieurs heures suite au retrait d’un paquet (https://www.numerama.com/tech/154759-comment-une-marque-commerciale-et-11-lignes-de-code-retirees-ont-fait-trembler-internet.html ).

Une démonstration du processus de contribution à conda (bug reports, merge requests, tests automatisés…) a aussi été présentée.
La gestion de l’environnement (par exemple disposer de la bonne version de MPI) n’est pas évidente. Loïc Gouarin a proposé une contribution pour simplifier cette gestion.
Un problème général des gestionnaires de paquets est qu’ils veulent tout contrôler, et qu’ils gèrent mal l’interaction avec les systèmes de gestion de paquets du système d’exploitation (pilotes, MPI…).

Le problème de base résolu par conda dans Anaconda est de fournir un gestionnaire de paquets aux utilisateurs Windows et MacOS qui n’en ont pas par défaut sur leur système d’exploitation, tout en étant portable d’un système d’exploitaiton à un autre, ce pour un environnement Python.
L’extension aux langages non-Python émerge naturellement des bibliothèques natives utilisées par Python (ex: numpy, matplotlib)

Loïc a utilisé `doitlive — doitlive 4.0.1 documentation <https://doitlive.readthedocs.io/en/latest/>`_ : on enregistre une série de commandes bash pour faire une démonstration et elles sont rejouées sur les machines clientes (un ou plusieurs caractères enregistrés par frappe clavier, c’est configurable).

Un biologiste a fait la publicité de Nextflow (https://www.nextflow.io/ ), un gestionnaire de graphe de tâches pour le calcul distribué. Cela se rapproche de Dask (https://dask.org/ ).
Dans les deux cas, on donne un graphe de tâches au gestionnaire qui gère alors la distribution des calculs sur plusieurs nœuds, sur du cloud…

Conférences Spark

Julien avait été convié à présenter ses travaux sur l’utilisation d’Apache Spark en astronomie au MeetUp Spark + AI de Londres ( https://www.meetup.com/fr-FR/Spark-London/events/254679118/ ). Ce dernier était organisé conjointement avec le Spark Summit ( https://databricks.com/sparkaisummit/europe/schedule ), une grande conférence sur Spark, à laquelle Julien n’avait pas prévu de se rendre en raison du tarif élevé. Cependant, les organisateurs du Summit (Databricks) lui ont offert un ticket, donc il y est finalement allé.

Julien a présenté ses travaux en compagnie d’une personne qui faisait du traitement automatique de la langue à des fins commerciales. Il a découvert au cours de ces événements que les utilisateurs de Spark dans le milieu privé se confrontaient finalement à des problématiques similaires à celles des chercheurs :

  • des difficultés à utiliser efficacement les machines disponibles ;
  • une réconciliation délicate des besoins de traitements groupés et interactifs ;
  • des choix cornéliens entre clusters maison un peu bricolés et cloud plus « propre » mais posant des problèmes de confidentialité ;
  • des personnes qui font tourner leurs jobs sur leurs ordinateurs portables en désespoir de cause…

Un thème très représenté était l’étude de la pertinence de l’utilisation des moyens HPC. Historiquement, il y a eu une forte propagande contre ces derniers, perçus comme moins performants et peu rentables. Cependant, on peut se demander dans quelle mesure ces rumeurs étaient fondées, et dans quelle mesure elles relevaient de la simple campagne de désinformation portée par les acteurs commerciaux du cloud et des grilles. En effet, des analyses rigoureuses montrent que les performances des deux moyens de calcul sont similaires, voire que la comparaison est parfois à l’avantage du HPC.

Par exemple, les études portant sur les systèmes de fichier distribués (Lustre, HDFS, S3…) montrent que sur des tâches usuelles de grandes lectures séquentielles, les performances de ceux-ci sont comparables. On aurait pu s’attendre à observer des différences étant donné que l’architecture varie beaucoup d’un système de fichier à l’autre (pair-à-pair, maître-esclave…), mais il est probable que sur ces cas d’utilisation simples, on soit limité par la bande passante des disques et des interconnections réseau, et non par le système de fichier utilisé.

La répartition des données entre noeuds (« shuffle ») est un point sensible pour de nombreux utilisateurs de Spark. Or, les études menées sur des machines HPC montrent que celles-ci ont un avantage sur ce type de tâches, qu’elles peuvent parfois effectuer trois fois plus rapidement que des machines HTC (grille, cloud…). On peut le comprendre en prenant en compte le fait que les machines HPC ont des interconnections très rapides de type Infiniband, qui ont en particulier des caractéristiques de latence bien meilleures que celles des réseaux Ethernet classiques. Un autre avantage du HPC est l’homogénéité des configurations matérielles, qui simplifie le déploiement de logiciels fortement optimisés et évite dans une certaine mesure les problèmes d’équilibrage de charge.

Finalement, la principale différence notable de mentalité entre secteurs privés et publics concernait les coutumes sociales. Ainsi, l’utilisation de cartes de visites demeure fréquente dans le secteur privé, là où elle est anecdotique dans le milieu académique. Il est possible d’en faire imprimer par le laboratoire, cela peut être intéressant pour ne pas être pris au dépourvu lorsqu’on se rend à ce type de conférences. Les thématiques et techniques commerciales (ex: vidéos promotionnelles) étaient aussi beaucoup plus présentes. À l’inverse, il était aussi inattendu qu’agréable de constater que le public écoutait l’orateur plutôt attentivement, au lieu de regarder son ordinateur ou son téléphone en même temps comme c’est généralement le cas en recherche.

Dans l’ensemble, le Spark Summit s’est avéré moins enrichissant que le MeetUp. Les discussions étaient souvent moins intéressantes sur le plan techniques, et les orateurs moins talentueux. Les plénières étaient aussi très autopromotionnelles (sans-doute avaient-elles été confiées aux soutiens financiers qui payaient le loyer de l’énorme centre de conférences, comme cela se fait souvent), et les sessions parallèles si nombreuses (7 à la fois) qu’il en devenait trop facile de mal choisir.

Une thématique qui revenait souvent était celle de l’apprentissage automatique, supervisé ou non. On parle d’apprentissage supervisé lorsqu’on fournit au système des exemples précis du comportement que l’on souhaite lui voir prendre lors de la phase d’ajustement des paramètres. L’apprentissage non supervisé, historiquement minoritaire car plus difficile, a connu un regain d’intérêt récemment alors qu’il commence à y avoir une prise de conscience des nombreux biais de l’apprentissage supervisé (performance qui dépend fortement de la diversité des données d’entraînement, mauvaise gestion des événements rares ou imprévus…). Un exemple de situation où l’utilisation de techniques d’apprentissage non supervisé est nécessaire est la détection d’anomalies, où l’on cherche à isoler des données qui dévient de façon peu prévisible des observations historiques.

Parmi les présentations plénières mémorables, on peut mentionner celles de Shell et Microsoft. Shell présentait un système d’analyse d’images de vidéosurveillance de station-service, qui pouvait détecter rapidement les fumeurs et ainsi oeuvrer pour la sécurité des biens et des personnes. Cependant, il était crispant de noter que le système collectait bien plus d’informations des vidéos que ce qui était nécessaire pour cet objectif affiché… Quand à Microsoft, il se sont plutôt illustrés par le ridicule puisque leur plénière consistait en une vidéo promotionnelle suivie d’un commentaire de la vidéo.

Parmi les sessions parallèles, globalement décevantes, Julien a relevé une belle présentation d’Enric Tejedor, qui organisait le Google Summer of Code au CERN cette année.

Les vidéos du Spark Summit sont disponibles à l’adresse https://databricks.com/sparkaisummit/europe/spark-summit-2018-keynotes?mkt_tok=eyJpIjoiTWpOak5UWTBObVV3T1RBMCIsInQiOiJPSklQMks3SzlkUmxwVDJCWEhSYzljR0NqOWliT2ZaUjR5bUNqcmZUNG1cLzkweUdsWW54Nkloalp3QWZoTDlZM1I2ekJYcFd0cEZ5Z0tMcHYxbEZiVXV4V3BBOGtrY2xDTWJUblpaVmIxXC96QitZVlVLUkMxSXpmbG5tcWJkUU1oIn0%3D .

Autres sujets

L’équipe pédagogique de la formation au génie logiciel du master NPAC s’interroge sur l’intérêt de présenter le typage optionnel en python. Ces « type hints » ont été introduites par la proposition de fonctionnalité PEP 484 [https://www.python.org/dev/peps/pep-0484/ ].

David aurait bien aimé encourager son stagiaire Cyril à parler de la banque de tutoriels « Coding Pool » qu’ils développent ensemble, mais il s’y est mal pris pour cette fois. La présentation est donc remise à plus tard.

Réunion du 27 septembre 2018

JI

Parmi les contributions du LAL, sont prévues :

  • Spark et programmation fonctionnelle, présenté par Christian (Julien sera finalement à Londres pour présenter les travaux au Spark+AI summit meetup).
  • C++ avancé, présenté par David
  • une démonstration d’un site sur les didacticiels IN2P3 par David, hébergé sur l’infrastructure du CC, dès qu’une image de ce site sera prête. Ce site a été fait en flask/viewJS/sqlite.

Site des didacticiels IN2P3

La liste des didacticiels disponibles s’affiche et permet de sélectionner les étiquettes discriminants. Par exemple, cliquer sur  « programmation » affiche seulement les étiquettes « C++ », « exploitation », « Python », car les autres étiquettes sont dans tous les didacticiels. Une étiquette IN2P3 sera ajoutée.

Les étiquettes sont en français et anglais, les étiquettes de la personnes recommandant le didacticiel sont enregistrées pour archive, puis éventuellement adaptés, d’une manière qui reste à déterminer.

Il est prévu d’ajouter les formations et journées de la communauté.
Les didacticiels ne sont pas archivés eux-même.
La question du RGPD et de la règlementation de la CNIL se pose pour la gestion des données privées si on enregistre les personnes qui recommandent les didacticiels.
Un grand nombre d’idées de développement existe (notation des didacticiels, écoles, etc.) et restent à intégrer.

Les didacticiels ont parfois été mis à jour sur le dépôt Gitlab MaitresNageurs.
Les dépôts ont été réorganisés mais les visiteurs passeront par le site lui-même et non les dépôts.

Root user workshop

Ces rencontres se sont déroulées il y a 15 jours à Sarajevo. Guy nous fait un retour sur ce qu’il s’y est dit.

Introduction du RDataFrame pour jouer avec les ntuples en cachant à l’utilisateur les « do loop » internes. L’idée est similaire à ce qu’on trouve dans Spark avec de la programmation fonctionnelle.
Les retours utilisateurs ont été nombreux :

  • ne plus avoir d’autogestion implicite des objets, d’où les RHistogram (namespace root namespace experimental) contrairement aux THistogram, qui complexifient la gestion des objets
  • tracé de courbe (RPlotting) qui permettrait de l’utiliser avec d’autres types de rendu (renderer openGL ou autre) via une réimplémentation du RDrawer
  • les « R »_experimentales sont dans la v6, la v7 devrait les intégrer « officiellement ».
  • Axel Neumann indiquait à Guy qu’il avait compris ses propositions faîtes dans son poster « namespace root », Guy s’interroge sur les suites possibles.

CERN/EP/SFT a 20 permanents et 20 personnes temporaires, et représente une partie importante des forces du CERN sur ROOT et GEANT4.

GEANT4 ne souhaite pas que leur dépôt soit public afin d’éviter l’utilisation dans les publications de code de physique non encore validé par la collaboration. Cela semble déjà s’être produit.

Réunion du 5 septembre 2018

JIs 2018

Les Journées Informatiques de l’IN2P3 et de l’IRFU se dérouleront à Port-Bail (près de Cherbourg) du 1er au 4 octobre.
De nouveaux trains sont apparus sur le site SIMBAD (départ St.-Lazare) ainsi que de nouvelles navettes sont apparues, et Christian a proposé un covoiturage. Cela rend la venue aisée.
Julien rappelle que pour utiliser son véhicule personnel, il faut une attestation de son assureur indiquant qu’on peut l’utiliser

évolutions du C++

C++ est un langage qui évolue régulièrement depuis 2011. Ces évolutions sont plus ou moins suivies selon les développeurs et leurs besoins.
Guy utilise plutôt C++98, mais la norme C++11 est assez utilisable sous GNU/Linux. C++14 ne semble, lui, pas encore totalement utilisable avec les compilateurs GNU/Linux.
Christian se demande quelle proportion des développeurs C++ utilisent les nouvelles normes C++11, 14, etc.
Il soulève aussi le souci de la viralité de Boost, souvent utilisée en C++, mais Hadrien souligne que l’usage massif d’un grand nombre de bibliothèques Boost est aussi dû à un manque de documentation de ces bibliothèques concernant les dépendances et les fonctionnalités utilisées, les développeurs intègrent donc plus que nécessaire pour se simplifier la tâche. Le système de compilation Boost est aussi complexe.

Pour rappel, l’intérêt du C++ 11 est…

  • davantage de fonctionnalités intégrées (smart pointers, alignement mémoire, type traits, hashmaps, expression rationnelles, threads…), donc un besoin moindre de bibliothèques tierces et peu standardisées ;
  • nouvelles syntaxes (initialisation par liste, inférence de type et boucle range-based) qui simplifient l’utilisation des types complexes de la bibliothèque standard STL (ex: itérateurs) ;
  • introduction du paradigme fonctionnel avec les lambdas (plus élégants pour certaines tâches comme la parallélisation, la récurrence et les requêtes sur un jeu de données) ;
  • la définition correcte des classes avec facilitée avec des outils comme =default, =delete, final et override
  • une nouvelle notion avec les objets déplaçables mais non copiables (utile pour modéliser des ressources ou l’opérateur de copie n’a pas de sens: handles de fichiers, connexion à des serveurs…)
  • Template variadiques: permet d’avoir des templates avec un nombre variable de paramètres de type (applications: tuples, printf…)
  • il est plus facile qu’avant de garantir que certains calculs seront effectués à la compilation (constexprs) ;

Une formation à C++ est proposée par David  avec la DR, les places sont comptées

  • C++ nouvelles pratiques ;
  • C++ templates (très utile pour le calcul entre autres) ;
  • C++ parallèle (lambda, threads standards, démo de MPI, OpenACC…).

Julien indique qu’en Python, certains commencent à éviter les lambda qu’ils considèrent moins lisibles et moins performants. Il se demande donc l’intérêt de les intégrer dans C++.
David pense que les développeurs python ne sont pas la cible la plus adaptée pour les lambda, vu qu’il s’agit de scientifiques sans forcément la formation informatique nécessaire pour les manier.

Sous windows, la gestion mémoire est plus stricte (?) et Visual/MSVC permet donc une détection de mémoire sans avoir à utiliser une bibliothèque comme Valgrind sous GNU/Linux.
Une version GNU/Linux existe de l’Interface de développement Visual.
Sous GEANT4, les batteries de tests lancées sur les mêmes programmes sous GNU/Linux détectent moins d’erreurs que sous Windows : est-ce dû à une détection plus efficace sous Windows ou à une gestion système et mémoire plus efficace sous GNU/Linux ? 

  • une version d’histogramme devrait être intégrée à ROOT7 (espace de nom « experimental »), écrite en C++14, mais elle ne fonctionne pas encore sur toutes les architectures ;
  • C++ a connu une évolution majeure avec C++11, puis des évolutions plus mineures avec C++14 et C++17. Le comité de standardisation a retenu la leçon: C++11 était si différent qu’il a fallu un temps très long aux compilateurs pour le supporter. Ils privilégient maintenant un modèle de développement plus itératif ;
  • le problème ressemble aux problèmes rencontrés par les architectures 64bits qui ont dû choisir entre la performance et la compatibilité avec les anciens programmes 32 bits. Le problème est aussi apparu pour le support SSL/TLS sur les serveurs web : il y a des vieux standard qui ont des failles cryptographiques connues, et des vieux clients qui ne sont pas compatibles avec les nouveaux standards. Il faut évaluer le nombre de clients qu’on embête pour décider quand on peut éteindre le vieux standard 

Conversion de SVN vers gestion de version décentralisé

GEANT4 souhaite passer sa gestion de sources de svn à Git. La raison n’est pas claire, mais un Gitlab CERN semble une des raisons.
Le dépôt de développement semble au moins partiellement nécessiter de rester interne.
L’existence d’outils tels que la gestion de méthode de travail (workflow) comme gitflow/hgflow semblent avoir son importance.
Des outils de migration existent, la communauté TANGO en a utilisé pour migrer de sourceforge (svn) à Gitlab (git).
Le choix d’abandonner svn semble cohérent, vers quoi est une autre question.
Un travail d’intégration de Mercurial dans Gitlab a été proposé récemment.
Un des inconvénients des gestionnaires de source décentralisés est la gestion des binaires. Cependant, des modules existent pour ceux-ci. 
Antoine a essayé Git LFS cet été, avec succès.

  • pour une intégration dans gitlab.in2p3.fr, il faut aller dans settings/general/permissions et activer Repository/Git Large File System
  • installer le client git lfs
  • « git lfs init » pour configurer un dépôt avec LFS
  • une icône LFS apparaît à côté des fichiers LFS

Avenir d’OpenGL

La conférence Apple a indiqué cet été que le support OpenGL est abandonné. Metal (bibli propriétaire) le remplace. D3D12 est l’alternative MS
Vulcan se veut le successeur d’OpenGL, mais Apple ne suit pas ce standard.
Ça pose un souci à la communauté GEANT4 car un grand nombre de Mac sont utilisés et ça a un impact sur iOS et MacOS

Docker

Antoine a essayé un analyseur statique de dockerfile : HaDoLint,développé en haskell. Il utilise un fichier de configuration intégrant les bonnes pratiques de la communauté (37 règles actuellement). 

Déplacement de la date de réunion

Un sondage est créé pour trouver une date quinzomadaire DevLal.

Réunion du 11 juillet 2018

JIs 2018 à Port-Bail du 1er au 4 octobre

La réunion précédente a permis de faire le point sur les contributions du LAL
Il y a actuellement 14 inscrits du LAL.
Tous les contributeurs n’ont pas encore reçu de retour des organisateurs pour savoir si leur contribution était acceptée.

Board-GitLab

Antoine présente le tableau de ticket (board) utilisé dans le contexte SVOM-MXT.
L’équipe est répartie dans plusieurs endroits, principalement au LAL et à Toulouse (CNES).
L’idée est de fournir une nouvelle version du logiciel, incomplet mais qui fonctionne, toutes les 2 à 4 semaines, en suivant la méthode agile Scrum.
Une seule liste de priorités est faite, nommée backlog.
Les jeux d’essais sont fait en internes par l’équipe, et les tests d’intégration sont fait par le responsable (CNES)

Une mêlée journalière est effectuée. Elle se fait d’habitude debout quand elle réunit tout le monde dans le même lieu. Dans le cas de SVOM, où mes développeurs sont géographiquement répartis, on utilise un outil externe : slack (l’outil Mattermost a été déployé au LAL pour test, et une instance framateam est disponible sur framasoft). Les questions qui sont posées dans ces mêlées sont brèves :

  • qu’ais-je fait depuis hier ?
  • que fais-je aujourd’hui ?
  • quelles sont les difficultés auxquelles je me heurte ?

Slack est aussi utilisé pour les communications régulières entre membres de l’équipe.
Les tickets utilisent des étiquettes :

  • 1, 3, 5, 10, 20, 40, 100 qui est le nombre de jours affecté à la tâche selon le temps nécessaire estimé, ordonné par durée croissante (de couleur verte) ;
  • le type de tâche : bug et critical, de couleur rouge ; doc, de couleur jaune ;
  • le nom de la colonne qui peut être à faire (to do), en cours  (doing) avec une couleur dédiée aussi, relecture (review), ou fait (done).

On décompose le projet en tâches au début.
Le backlog est ensuite mis à jour à tout moment.
Une colonne « review » demande la relecture par les autres développeurs, pour ensuite être basculée dans « done » ou « à faire » selon le résultat de la relecture.
En théorie, le responsable produit (product owner) est indépendant de l’équipe. Dans SVOM, il est membre de l’équipe et il arbitre les choix si besoin.
Le projet est décomposé en étapes (milestones), auxquelles sont affectuées les tâches.
Le déplacement d’une tâche d’une colonne à une autre change le label autiomatiquement, il n’y a a priori pas d’autre automatisation possible.
Julien indique que Github ne permet pas encore l’automatisation du changement de label sur changement de colonne, Philippe indique que kanboard permet une automatisation plus complète sur chaque action, y compris en intégrant des actions externes, c’est cependant moins simple qu’un outil intégré à une forge sociale comme GitLab.

La gestion des exigences se fait dans le wiki gitlab, pour alimenter l’outil Rectify du CNES, grâce à des balises XML. L’écriture se fait dans un clone de la branche master, et le test dans un fork personnel.
Le responsable scrum (scrum master) a pour tâche d’aider au fonctionnement de la méthode de développement SCRUM.

GSoC

2 étudiants ont échoué (pas du LAL!), c’est-à-dire que le mentor indique qu’ils ont abandonné le projet en cours : ils n’ont plus interagi avec eux ni envoyé de code.
Ce pourrait être dû à des difficultés techniques rencontrées.
La rémunération est versée mensuellement, ce qui maintient la motivation, et un des étudiants qui a abandonné avait pourtant validé la première partie sans souci.
Les mentors semblent tenter de trouver des solutions humaines lorsque des soucis apparaissent.

CHEP 2018

Michel, Guy, Hadrien et peut-être Grigory sont allés à CHEP à Sophia

Réunion du 27 juin 2018

LoOPS

Pour rappel, les événements sont affichés sur la page du réseau
Le prochain événement est un café LoOPS le 3/7 de 13h à 14h au Proto204.
Pour rappel, le café n’est pas ouvert aux seuls informaticiens, la preuve : David Rousseau nous présentera les défis de l’apprentissage automatique appliqué à la physique des particules.

JIs 2018 à Port-Bail du 1er au 4 octobre

Les dates limites sont le 7/7 pour les inscriptions et le 30/6 pour les proposition de présentations.
Concernant les contributions, il est possible de ne donner que le résumé pour la soumission.
Les contributions prévues par le LAL sont :

  • un plongeon par Christian sur les aspects multi-langages
  • un plongeon qui aborde des aspects de la programmation fonctionnelle avec Scala
  • une présentation de 20 min sur l’analyse de données astronomiques avec Apache Spark
  • une présentation du Dashboard de GitLab par Antoine 11/07

La journée des journées des nouveaux entrants à l’IN2P3 se déroule en même temps.

Divers

Formation Python: la communauté des développeurs Python est devenue importante, il est nécessaire de restructurer à la fois les demandes et les financements pour ce type de formations.

Au Royaume-Uni, la communauté des ingénieurs de recherche tente de s’organiser autour du logiciel durable. Ils suivent derrière Software carpentry, aux EU, la même communauté s’est nommée United Research Software Sustainability Institute (URSSI)

PacktPub propose sur inscription 1 livre informatique par jour.

AstroLab

Julien présente l’ébauche d’un nouveau site sur GitHub Pages, basé sur Jekyll. C’est donc une page entièrement statique.
L’édition dans GitHub Pages se fait en Markdown tandis que le formatage se fait par balise YAML.
Julien propose une présentation rapide :

  • le site aborde la programmation fonctionnelle et Spark pour la communauté scientifique ;
  • il sera déployé la semaine prochaine pour obtenir une reconnaissance par un label LSST, à la venue de Emmanuel Gangler ;
  • un des soucis est que les machines du CC IN2P3 ne sont pas dédiées à la R&D technologique et ne peut donc aider le projet ;
  • le site permet de centraliser les documents pour pouvoir communiquer un portail aux intéressés ;
  • Michel l’a mis en contact avec des personnes du CERN (CMS) qui bossent sur spark-root. Leur groupe a plusieurs étudiants GSoC et ingénieurs dédiés. Une réunion mi-juillet en visioconférence permettra de déterminer si une vision commune permet des projets communs.

Le besoin impérieux se fait sentir de trouver une jolie image pour jouer sur le nom du projet : par exemple ça
Serge rappelle aussi que les CMS peuvent générer des sites statiques, qui sont plus légers.

Contrôle-commande PRAE

PRAE est un ensemble accélérateur + détecteur monté par plusieurs des labos qui vont fusionner.
A priori, le contrôle-commande sera basé sur une réutilisation des technos développées dans le cadre de ThomX, pour le matériel comme le logiciel (TANGO) par Philippe et le groupe contrôle-commande. L’acquisition serait basée sur l’outil DCOD sur lequel le CSNSM et l’IPN ont une expérience importante.
Une réunion a eu lieu avec le CSNSM, l’IPNO, et le LAL pour planifier une organisation commune cohérente du pilotage en temps réel (mou) de l’ensemble.

Usage des wikis des forges sociales Gitlab (et Github ?)

Premier point d’attention : un dépôt Git de wiki peut être cloné mais pas forké.
Il n’y a aucune interface web pour voir sa branche, ce qui peut poser des soucis en cas d’édition simultanée.
L’édition simultanée via l’interface web est a priori déconseillée, mais en pratique, cela peut servir à vérifier que l’aspect obtenu correspond à ce qu’on souhaite.

Par ailleurs, et indépendamment du wiki de Gitlab, le Markdown intégré à Gitlab intègre des bibliothèques intéressantes, par exemple pour intégrer des diagrammes Gantt avec mermaid.
Créer une table des matières dans le wiki est aussi possible avec la syntaxe [[_TOC_]], peut-être est-ce aussi faisable en Markdown dans des fichiers.

Réunion du 13 juin 2018

Formation Hadrien git

La version originale d’Hadrien sur owncloud avec slides
Elle sera revue et corrigée courant Septembre, en fonction des retours de la 1ère session, puis rejouée en fin d’année.

Le portage « piscine »

https://gitlab.in2p3.fr/MaitresNageurs/GenieLeaugiciel/

  • JIs 2018 à Port-Bail du 1 au 4 octobre
  • dates limites : inscriptions 7/7 et soumissions 30/6
  • qui ? Julien, Antoine, Hadrien
  • contributions du LAL Julien:
    • 1 piscine (Scala) + 1 talk (Analyzing astronomical data with Apache Spark)
    • Antoine: Plongeon Sphinx (David: …et Gitlab Scrum ?)
    • Hadrien: Présentation-éclair (5 min) sur openSUSE Tumbleweed, une distribution Linux qui rend le modèle « Rolling Release » plus utilisable grâce à un accent important sur l’assurance qualité et la restauration système en cas de pépin. Peut-être quelques chose (pres? tuto?) sur le langage Rust.

Le format éclair n’est pas évident… (on doit souvent faire avec 1-2 diapos).

Rencontres Tango à Prague

  • TANGO est un Bus logiciel utilisé sur ThomX, concurrent d’EPICS, apparu en Europe (SOLEIL et ESRF) au moment du schisme survenu entre deux versions de ce dernier
  • il permet de contrôler (lire) et commander (écrire) plusieurs nœuds de plusieurs endroits différents
  • la communauté est composée de 46 institutions, principalement des accélérateurs / synchrotrons, mais aussi la soufflerie de l’Onera à Toulouse, des bouts du laser Mégajoule, le détecteur astro SKA
  • Passé en v9 depuis un an, il utilisait pour la communication entre processus CORBA depuis le début, et a entamé une migration progressive vers ZeroMQ
  • Principaux développeurs du noyau : SOLEIL, ESRF (fondateurs), ALBA, et Elettra. 6 autres institutions font partie des contributeurs de la Fondation TANGO et participent à niveau moindre en temps et en argent pour donner les orientations
  • d’autres institutions proposent des outils clients et interfaces utilisateurs
  • ElasticSearch pour la gestion des journaux contrôle-commande
  • les distributions utilisées sont diverses, et les paquets sont recréés par différentes institutions. Une discussion est en cours pour mutualiser le travail de création et maintenance des paquets sur Debian, CentOS…
  • MaxIV ont proposé eloggy, une évolution de eLog avec des fils de discussion et une base de données pour remplacer la configuration par fichier texte.
  • Des discussions improvisées ont eu lieu sur le rachat de GitHub par Microsoft (l’information est tombée le jour de début des rencontres, et la migration à GitHub de la communauté Tango ne datait que d’un an)
  • La fondation Tango pourrait héberger un GitLab, puisque chaque institut a sa propre instance Gitlab. Mais il y a un compromis avec le côté visibilité, communauté mondiale… de GitHub.

Forges sociales

  • Les forges sociales ont centralisé une partie une partie des usages de gestionnaires de version décentralisé, c’est la visibilité qui semble la raison qui légitime cette centralisation. Quelques systèmes de gestion de version décentralisés intègrent nativement des fonctionnalités de forges sociales comme les tickets (FOSSIL semble le dernier survivant)
  • L’avantage d’une forge centralisée comme GitHub est qu’elle permet d’avoir des nouvelles « triées » sur les nouveaux projets. Mais la manière dont sélection est faite influe sur la communication des projets. Le projet git-federation a été lancé il y a quelques jours afin de permettre de permettre cette synchronisation sans imposer une centralisation. GitTorrent fait du Git par dessus le protocole pair-à-pair BitTorrent. Bridgy sait parler Github aussi, il permet d’afficher des infos Github sur une page web comme les publications des réseaux sociaux. SSB est un projet pour faire une forge pair-à-pair.
  • Les forges (ex: gitlab) hébergent aussi des informations personnelles dans les informations de commits (champ identité qui comporte une adresse électronique et un identifiant, qui peuvent permettre d’identifier l’auteur). Cela a soulevé dans la communauté le problème de comment respecter le droit à la suppression des données personnelles du RGPD. Le changement de l’identité des commits créerait une nouvelle branche, mais cela ne changera rien pour tous les autres dépôts qui ont été créés à partir du dépôt public
  • Pourquoi on doit donner son mail dans un gestionnaire de version ? Historiquement, Linus Torvald (créateur de git) tenait à envoyer les modifications par courrier électronique mais cela n’est qu’une information falsifiable et modifiable.
  • L’adresse électronique est un des moyens naturel d’identifier de manière unique un auteur (ou un commiter), il y en a d’autres. Une évolution possible serait d’utiliser une clé GPG à la place. La possibilité de signer ses modifications est d’ailleurs déjà intégrée à Git et Mercurial.

Nouvelles de PSPA ?

  • Des ingénieurs ergonomes ont commencé à s’entretenir avec les utilisateurs potentiels.
  • La proposition finale ne révolutionne pas, c’est un processus d’amélioration itérative, mais de nombreux détails importants ont été évoqués et améliorés.
  • Ex: pour eux, une bonne interface ne nécessite pas de fonctionnalité pour revenir en arrière, mais va dans le sens d’un avancement continu vers un but. Cette règle n’a cependant pas été suivie tout le temps.
  • Ils ont donc revus plusieurs itinéraires dans l’interface de PSPA en fonction de cette bonne pratique.
  • Maintenant, on passe à la phase implémentation, et c’est une équipe web basée à Bordeaux qui prend le relai.
  • Deux points imposés par le LAL: contrôleur en python et utilisation de frameworks (pas dans leur culture)
  • Différence: l’entreprise travaille dans l’idée qu’on développe une fois et arrête après, le LAL vise plus pour PSPA un modèle de développement continu
  • Démonstrateur en Flask + Vue.js + C encapsulé avec Cython. Dispo sur le Gitlab du CC.
  • Accord de principe du commercial avec ces contraintes techniques (à budget identique).
  • Transition technologique XML vers JSON (pour un meilleur interfaçage JavaScript) et C vers C++
  • Une différence importante: XML est ordonné (plus précisément, les bibliothèques qui le décodent le présentent comme tel), JSON ne l’est pas. Des différences d’interface logicielles existent, il va falloir imposer l’ordre dans le schéma JSON

Nouvelles de GSoC ?

  • les 4 labos français qui participent semblent très contents

Misc

  • NSIP
    • Des soucis ?
    • La vidéo tutoriel indisponible était due à une mauvaise utilisation d’atrium pour créer le lien pérenne
    • La mention légale avait été recopié à la va-vite, sans rayer les mentions à rayer
    • NSIP est utilisé actuellement pour évaluer les ETP sur projets, pas pour comptabiliser précisément le travail. La durée totale ne doit pas excéder la valeur maximum, mais peut être inférieure
  • Serge: Les collègues du CEA souhaitent utiliser l’OpenStack du LAL pour SVOM en attendant que l’infrastructure au CC soit prête.
    • Le LAL fournit pendant la transition, et comme dépannage, dans l’idée de transiter vers le CC dès que c’est prêt.
    • Presque opérationnel, rendez-vous avec les gens du CEA demain pour tester la plate-forme.
    • OpenStack constitue une avancée majeure en terme de fiabilité et documentation par rapport à StratusLab, qui était en phase de R&D.
    • SVOM présent sur le tableau de bord OpenStack depuis ce matin seulement…
  • Christian par mail: « SKA c’est impressionnant 600 x LSST en terme de data flow
    • 700 Pb / year (-> 50 ans)
    • 120000 antennes
    • bof on se sent très petit joueur avec LSST !! »

Réunion du 15 mai 2018

LoOPS

  • retour journée Meson ?
    Meson est un outil de compilation et construction de binaires.
    Aucun membre du SI ne s’est déplacé à cette journée.
  • prochains cafés le 1er mardi de juin sur le RGPD et Track ML en juillet par David Rousseau (LAL)

git/GitHub/GitLab

  • formation Hadrien (aura bientôt besoin de relecteurs !)
  • Demandes de présentations locales (exploitation SI / DEPACC)
  • problème actuel de Antoine : sous git, on pousse un commit de PNG, puis on le modifie, puis on le pousse : c’est refusé alors que ça fonctionne sous hg

informatique au CAPES

L’épreuve d’informatique au CAPES de maths, session 2018 !
Il n’y a pas de CAPES d’informatique, mais une option informatique au CAPES de mathématiques.
Par ailleurs, depuis plusieurs années, des informaticiens militent pour une agrégation d’informatique (actuellement, les cours de classes préparatoires sont donnés par les agrégés de mathématiques).

AOB

JIs 2018/piscines
Peu de nouvelles des JIs, les gens sont probablement submergées… mais on n’est plus si loin ! (Voir réunion du 12/06)

RGPD

C’est la directive européenne de protection des données, une sorte de loi informatique et liberté européenne. Elle vient en plus de la loi française, qui sera harmonisée avec plus tard.

  • analyse NextImpact
  • FLOT « Protection des données personnelles : le nouveau droit&#8239»
  • Présentation d’Émilie Masson du service informatique et libertés du CNRS, qui est la correspondante CIL qui s’appellera au 25 mai 2018 la DPD (Déléguée à la Protection des Données, c-à-d la DPO ou Data Protection Officer). «Les données à caractère personnel et leurs traitements: le Règlement européen pour la protection des données (RGPD)&#8239 qui prendra effet le 25 mai 2018 en Europe ;
  • Programme, présentations et vidéos du reste de la journée Inframed2017
  • sur les infrastructures sur les données de santé
  • séminaire Aristote

Prochaine ANF (Action Nationale de Formation)

sujet la programmation fonctionnelle (en proposition) :

  • Idée du programme : 1,5 jours de théorie + 2,5 jours de pratique.
  • Lieu : Aussois ? Cargese ?
  • C’est quoi le fonctionnel?
  • Comment on pense fonctionnel?
  • Le fonctionnel fleurit dans les langages HEP et Astro usuels (Python, C++…), comment en tirer le meilleur parti?

Je dirais plutôt que les langages HEP usuels intègrent des possibilités de faire (un peu) de fonctionnel, et donc en effet, comment en tirer le meilleur parti?

  • Quels cas d’utilisation?
  • Contrôle-commande: Tango intègre une bibliothèque permettant des fonctionnalités fonctionnelles (fandango), par exemple pour les expressions rationnelles

réunion interAG SI

  • faire du SCRUM avec les tickets Gitlab/Gihub
  • On peut avoir une vue des tickets sous forme de tableau Kanban (« colonnes de tickets »). Passer les tickets d’une colonne à l’autre est implémenté avec un jeu de tags sur les tickets (1 tag par colonne).

SVOM s’inspire de Scrum plus qu’il ne l’applique.

Docker

  • Installation de docker sous Windows ? Toujours un peu complexe, différences entre pre-10 et Win10, entre différentes générations/gammes de processeurs (fonctionnalités matérielles liées à la virtualisation)…
  • Permet d’avoir à la fois un outil de démarrage rapide et un guide d’installation locale
  • Permet de tester la portabilité (inter-OS, inter-compilateurs) plus facilement qu’avec des VMs, puisque ça permet au développeur de recréer le même contexte que l’utilisateur
  • intérêt pour cloisonner des installations différentes, pour des projets différents (les dépendances de bibliothèques sont différentes pour chaque projet)

Python

Qui fait du pipenv ? Antoine est convaincu, suite aux exposés de PyCon 2018, personne d’autre ne semble avoir été plus loin que le test isolé pour l’instant.
C’est le remplaçant des virtualenv de python

Qubes OS

OS orienté sécurité et vie privée, qui lance des VMs différentes selon l’activité à laquelle on se livre, et les présente sous la forme d’une interface graphique unifiée.
Bonne vidéo de présentation de 30min sur le site
Utilisation possible dans des contextes où on n’a pas confiance (ex: connexion internet douteuse): si il y a un soucis, il suffit de jeter la VM.

GSoC (google summer of code)

ça démarre doucement
Familiarisation avec l’environnement de travail, les publis, le code…
Les modalités d’évaluation conjointe ont été publiée (ex: questionnnaire des années précédentes)
La formule change tous les ans pour s’adapter aux observations de l’édition N-1.

sécurité

le FLOT ANSSI sur la sécurité des usages est terminé.
Il était très intéressant mais n’aborde pas la sécurité du point de vue développement.

PSPA

On entre dans le vif du sujet : 3 ateliers se sont déroulés avec l’entreprise CGI (qui va s’occuper de l’interface web de l’application)
But: faire émerger les besoins des utilisateurs PSPA
On fait des post-it de besoins, on classe, et il en résulte une idée d’interface, concrétisée en une maquette
Beaucoup d’inspiration de Sirepo
Interfaces différentes selon les besoins et entrées : saisie de données/méta-simulateur avec un bus de données commun