Les joies du déploiement

Antoine travaille sur un conteneur Wt pour PSPA. Ce dernier est basé sur une image Docker qui communique avec l’hôte par le biais d’un port réseau local. Mais récemment, le script qui initialise le conteneur a cassé et il ne comprend pas pourquoi. Toute aide pour débugger ce comportement serait la bienvenue.

Simultanément, l’équipe ThomX se pose la question de la distribution des binaires, qui se fait actuellement par le biais d’images ISO. Existe-t’il une solution plus simple de mise en oeuvre et mieux intégrée à leur gestion de version Git ?

Au niveau simplicité, tout dépend du degré auquel on descend à bas niveau. Docker marche bien pour de l’applicatif, mais ne sera pas forcément adéquat dès lors qu’on doit communiquer directement avec le noyau du système d’exploitation ou un pilote de matériel. A ce niveau, Philippe mentionne que l’un des buts pour ThomX est de déployer des pilotes TANGO.

Guy utilise différents mécanismes suivant la plate-forme cible. Par exemple, l’App Store d’Apple a des contraintes bien à lui. Quand il doit distribuer des programmes directement, il préfère lier statiquement un maximum de dépendances, même sous Linux. Windows et macOS sont mieux adaptés à ce mode de déploiement.

Dans tous les cas, il est important au moment du déploiement de savoir de quelles bibliothèques on dépend. A ce niveau, ldd et son équivalent Windows sont d’une grande aide, même si ils ne sont pas omniscients (par exemple, ils ne détectent pas les chargements dynamiques de bibliothèques à la dlopen()).

Pour ce qui concerne l’intégration avec Git, il y a eu des évolutions intéressantes ces dernières années autour des environnements GitHub et GitLab. Par exemple, on peut facilement automatiser le déploiement d’un binaire ou la mise à jour d’un site web chaque fois que l’intégration continue se passe bien.

Lorsqu’on a besoin de mettre des gros fichiers binaires dans un dépôt Git, il peut être intéressant de regarder ce qui se fait du côté de l’extension Git LFS (Large File Storage), co-développée par GitHub et Atlassian. Celle-ci a été pensée pour des usages où du code qui varie rapidement dépend de gros fichiers binaires qui varient plus lentement, par exemple pour les modèles 3D et textures dans les applications graphiques. Au niveau des inconvénients, l’extension est relativement jeune et en évolution rapide, ainsi Guy avait rencontré des problèmes de dépôt brisé lorsqu’il avait essayé il y a quelques temps.

Antoine mentionne aussi que l’équipement de développement Git s’intéresse actuellement aux idées du projet Evolve de Mercurial, qui vise à rendre les modifications d’historique (rebase, amend et compagnie) un peu moins dangereuses. Espérons que cet effort ne sera pas lui aussi condamné au destin d’éternelle beta…

Projets et communautés

Atrium

Christian nous annonce que l’INSU et l’IN2P3 se sont finalement mis d’accord pour utiliser tous les deux Atrium, ce qui est une première dans les relations politiques tendues entre ces frères ennemis. Ils ont même conjointement décidé de financer un CDD pour assurer sa maintenance.

Globalement, l’outil croît raisonnablement au LAL et à l’IN2P3 en général. Il est notamment bien accepté dans ThomX, mais les membres de PHIL sont plus hésitants.

LoOPS, Xtensor et Vue.js

LoOPS joue le 5 décembre un café sur Xtensor, une bibliothèque pour manipuler des tableaux multidimensionnels avec une interface utilisant des concepts similaires à MATLAB et NumPy. Cette bibliothèque possède une communauté assez active sur le plateau de Saclay.

Guy regrette l’usage du C++14, qui ferme des portes quand on veut rester portable avec des plate-formes dont les compilateurs C++ ne sont pas maintenux à jour par rapport aux évolutions du standard. En un sens, on observe dans la communauté C++ un schisme comparable à celui entre Python 2 et Python 3 (le premier n’est plus maintenu, mais de nombreuses infrastructures n’ont toujours pas sauté le pas).

En cadeau de Noël, LoOPS rejoue aussi le 19/12 sa présentation sur Vue.js, un framework Javascript pour le développement web front-end qui s’oppose à des solutions plus connues comme React et Angular par son approche plus « légère ».  Angular a aussi une réputation de briser davantage la compatibilité.

Hébergement de tutoriels

Hadrien commence à accumuler différents tutoriels et supports de formation autour de la performance logicielle, de différents types (slides, wikis, code…), et se demandait si il y avait un bon endroit dans les communautés académiques auxquelles on a accès (CNRS, RENATER, IN2P3, CERN, etc…) pour héberger tout ça.

En pratique, il s’est avéré que la contrainte la plus stricte sur ce genre était la volonté de donner facilement accès en écriture à d’autres personnes. A ce niveau, l’hébergeur le plus sympathique dans nos communautés académiques semble finalement être le CCIN2P3, qui accepte d’ouvrir des comptes à des extérieurs sur simple demande administrative d’un personnel IN2P3.

Deux solutions y ressortent comme particulièrement intéressantes:

• Atrium, dont on a parlé précédemment, est un système de gestion de documents, plutôt orienté vers du contenu relativement immuable sur lequel on souhaite appliquer des politiques d’accès ou d’édition complexes. Il y a un support préliminaire de l’édition en ligne, mais ce n’est pas la spécialité de l’outil.
• Gitlab, une plate-forme de gestion de code source avec de nombreux à-côtés sympathiques (wikis, sites web statiques), qui semble mieux adapté pour le code et les contenus collaboratifs.

WebAssembly

En ce moment, il y a pas mal d’activité autour de WebAssembly. Il s’agit d’un projet pour standardiser un bytecode universel pour le développement front-end web, afin de faciliter le développement de composants d’applications web dans d’autres langages que Javascript (typiquement pour des raisons de performances).

Le projet est comparable dans son intention au projet PNaCl (Portable Native Client) préalablement proposé par Google, mais contrairement à ce dernier il a réussi à faire l’unanimité auprès des développeurs de navigateurs web (y compris Apple et Microsoft, traditionnellement les plus difficiles à convaincre).

WebAssembly se veut être le successeur spirituel d’asm.js, un sous-ensemble de construction Javascript bas niveau orienté performances vers lequel on transpile parfois du code C/++ pour des besoins comme le développement de jeux vidéo.

Hadrien en a entendu parler via la communauté Rust, qui s’y intéresse beaucoup et en a récemment fait un backend du compilateur officiel.

Community White Paper

La HEP Software Foundation est actuellement en train de finaliser son « Community White Paper », un papier qui recense des idées et plans pour les développements logiciels à venir dans la physique des particules.

Guy s’interroge sur le périmètre du document. Il ne comprend pas pourquoi une fondation qui, dans son titre, se positionne comme focalisée sur les questions de logiciel, concentre une partie significative de son papier sur des questions d’infrastructure système. Antoine répond qu’il existe un lien fort entre les deux: sans un computing solide sous le capot, point de salut pour le logiciel… Mais dans ce cas, pourquoi ne pas l’appeler « Hep Computing Foundation », HCF, en prenant exemple sur le nom de la conférence CHEP ? Et n’existe-t-il pas un risque de dispersion des efforts ?

Une autre question de périmètre se pose au niveau des expériences. Le document conserve actuellement une très forte teinte (HL-)LHC, les autres expériences n’étant que brièvement mentionnées. Or, si l’on ne parvient pas changer cela, prétendre parler au nom de l’ensemble de la communauté de la physique des particules devient pour le moins présomptueux…

Guy est aussi peu satisfait de la partie visualisation, qu’il trouve incomplète et encore une fois biaisée en faveur de l’écosystème LHC. Il a tenté d’y contribuer, notamment en défendant l’importance d’applications locales autonomes, mieux découplées de l’infrastructure d’analyse des expériences. Mais le modèle client-serveur demeure finalement favorisé dans le texte final.

Le rôle réservé à Python pour l’analyse est intéressant: on accepte la popularité grandissante de ce langage, mais ne considère dans le texte que son usage en compagnie de ROOT, via PyROOT.

En vrac

Suite à un vol, Philippe est à la recherche d’un téléphone Samsung Galaxy S3 pour des besoins de développement bas niveau. Il est important que ce soit un S3 car l’écosystème ARM / Android est très pauvre en pilotes de matériel open-source, et peu de terminaux sont correctement supportés par Replicant, le fork open-source d’Android.

Il y a aussi eu une brève discussion sur le langage Go:

• Qui l’utilise ?
• Est-il désirable que ce soit utilisé davantage ?
• Si oui, comment on « vend » un nouveau langage aux expériences ?

La question du cycle de vie de l’expérience a été discutée : il est plus facile pour une expérience d’adopter une nouvelle techno, comme un nouveau langage, quand elle est au début de son cycle de vie. Mais même là, une nouvelle manip peut être liée à des technologies plus anciennes utilisée par une manip précédente.

Christian trouve qu’il est intéressant de faire un parallèle avec la transition de Fortran à C++ de la physique des particules dans les années 90. Beaucoup des arguments qu’on trouve aujourd’hui étaient déjà invoqués à l’époque, et à la fin l’histoire a montré qu’avec une motivation suffisante, une transition de langages est possible.