Développement au LAL

Présentations

La réunion a commencé par quelques présentations, car beaucoup rencontraient Julien, nouvelle recrue du SI, pour la première fois. Julien a été recruté sur des thématiques de calcul scientifique distribué, et va dans un premier temps travailler sur le logiciel de LSST avec Stéphane, Réza, Sylvie et Guillaume.

Serge s’est présenté comme ayant un pied dans le développement logiciel et un autre dans l’exploitation. Il est courant pour les développeurs web de contribuer ainsi à l’exploitation au LAL, mais ce n’est pas nécessairement le cas dans le reste de l’industrie où ces corps de métiers peuvent, de son expérience, être davantage séparés.

Accueil des nouveaux entrants

Julien mentionne qu’il ne reçoit pas les comptes-rendus de réunions. C’est lié au fait qu’on a oublié de l’inscrire sur la liste de diffusion DEV-LAL. Ce qui réveille la vielle question de l’accueil des nouveaux entrants et de l’intégration de ces derniers à l’infrastructure informatique : pour l’instant, cela reste un processus assez fastidieux et manuel, peut-on l’automatiser davantage ou au moins centraliser une liste de ce qu’il faut faire à chaque fois ?

Serge propose aussi la rédaction d’un guide des nouveaux entrants, qui présente à ces derniers les ressources informatiques disponibles, par exemple les mailing-lists importantes. La question de la maintenance d’un tel guide doit être préalablement élucidée, surtout dans un contexte de fusion de laboratoires où il est probable que les règles de fonctionnement informatique vont changer prochainement et de façon importante.

Organisation des réunions

Les développeurs du LAL organisent une réunion toutes les deux semaines, le mercredi matin à 10h30, qui dure une heure. L’un des buts de cette réunion est d’échapper au cloisonnement naturellement créé entre les différentes activités du LAL par le grand nombre de collaborations avec des manips « hors-sol ».

Le format de cette réunion change régulièrement. Actuellement, la formule choisie n’utilise pas d’ordre du jour, préférant une organisation à base de parole libre. Ce format a des avantages et des inconvénients: il donne plus de place aux sujets de conversation imprévisibles (ex: actualités) et aux personnes d’un naturel spontané, mais il convient moins aux personnes qui préfèrent préparer un sujet et au suivi sur la durée de sujets précis (ex: retours des café LoOPS annoncés à une réunion précédente).

Peut-être faudrait-il envisager un format plus hybride, où chaque réunion a une partie cadrée et une partie non-cadrée. A minima, on pourrait envisager de définir une structure guidée par la trame récurrente des réunions libres, Philippe propose par exemple :

• Actualités et futur proche
• Suivi des annonces précédentes (ex: retours des cafés LoOPS)
• Parole libre

Comme première expérience, on pourrait allouer 15 minutes à la partie cadrée et 45 minutes à la partie libre, et voir comment ça se passe.

Pour aller plus loin, on pourrait aussi envisager la rédaction d’un ordre du jour collaboratif avec un outil « léger » de type Etherpad. Le document serait pré-rempli avec la structure ci-dessus, et les gens pourraient librement y ajouter des points de discussion entre deux réunions. La structure ainsi définie pourrait aussi être réutilisée lors de la rédaction de comptes-rendus, et il en résulterait un gain de temps.

Une autre possibilité, préalablement évoquée mais qui n’a pour l’instant pas été mise en pratique, est de tourner entre les différents développeurs au fil d’une année, laissant à chacun l’occasion de présenter son activité à tour de rôle.

Serge mentionne qu’un travers du format actuel est qu’il peut souvent tourner au débat d’expert. Antoine rappelle que de tels débats sont aussi utiles, mais approuve qu’il vaut mieux qu’ils ne monopolisent pas la réunion pour autant…

Autre question: doit-on parler davantage de projets dans les réunions développeurs ? Christian popose pour ça de partir du compte rendu mensuel de la réunion ASPRO que nous envoie Michel, et de mettre nos questions sur ce dernier à l’ordre du jour. Pour rappel, ASPRO est une réunion mensuelle des chefs de projets du LAL, sur un format préparé à l’avance avec éventuellement un tour de table si le temps le permet.

Comptes-rendus

Hadrien sonne l’alarme: le format actuel des comptes-rendus, qu’il a inauguré, structuré et rédigé, est très apprécié mais il lui coûte aussi cher en termes de temps de rédaction. Typiquement, il faut compter entre un et deux jours à temps partiel pour produire un compte rendu, et à fréquence de toutes les deux semaines ça finit par représenter une part non négligeable de son temps de travail.

Plusieurs possibilités sont envisageables:

• On continue avec le format actuel, mais on répartit la charge entre plusieurs personnes. Par exemple, on pourrait alterner entre deux secrétaires de séance d’une réunion à l’autre. Cela aurait aussi pour avantage de fournir une solution évidente pour les réunions où Hadrien n’est pas présent.
• On reste avec un secrétaire de séance unique, mais on sacrifie la qualité du document, par exemple en passant à un format moins rédigé ou moins structuré. C’est moins satisfaisant en termes de résultat final, mais ce sera l’approche la plus facile à adopter si personne ne se manifeste pour aider.
• On essaye d’abandonner complètement le concept de secrétaire de séance unique au profit d’une approche plus collaborative de type Etherpad. Celle-ci reste cependant à définir:
  • Si tout le monde est responsable pour prendre des notes, personne ne l’est, et de l’information sera perdue. De plus, l’activité de prise de notes freine grandement la participation à la réunion, donc on ne veut pas forcer tout le monde à prendre les siennes de façon redondante.
  • Quel outil de prise de notes utiliser ? Mieux vaut éviter une prolifération des ordinateurs en réunions, qui tendent à être distrayants et à freiner la communication entre personnes (au profit de tâches individuelles comme la gestion des e-mails). Mais les notes manuelles doivent être recopiées, ce qui induit aussi une charge de travail conséquente.
  • Comment centraliser les notes à la fin et s’assurer qu’elles soient mutuellement intelligibles ?
  • Qui se charge de la mise en page et de la rédaction finale ?

Cette discussion sera poursuivie prochainement, par exemple en faisant un petit sondage par e-mail sur les avis du groupe de développement à ce sujet.

Distribution de binaires

La question de la distribution de binaires pour le contrôle-commande demeure encore irrésolue. C’est en effet actuellement un peu complexe quand on utilise le Gitlab du CCIN2P3.

Philippe essaye actuellement de distribuer les binaires via l’ownCloud du LAL, mais il y a des erreurs à l’upload avec de gros fichiers (~3 Go) même quand il y a assez de place dans le dépôt. Gérard essaye actuellement d’examiner les quotas du serveur afin de comprendre ce phénomène. Si le problème n’est pas là, une autre possibilité serait que quelqu’un ait encore fait la boulette d’utiliser un entier signé 32-bit pour stocker des tailles de fichier quelque part dans le code source d’ownCloud ou de ses dépendances. Ce serait loin d’être la première fois…

Idéalement, il n’y aurait pas besoin de séparer les binaires du code source versionné, et on pourrait directement gérer ces derniers depuis l’interface Gitlab à la manière des pages « releases » de Github. Une possibilité serait de faire appel à la fonctionnalité Git LFS (Large File Storage), mais cette dernière ne pourra pas être introduite au CC tant que ce dernier n’aura pas effectué la mise à jour à Gitlab 10…

Christian propose d’utiliser Atrium à la place d’ownCloud. Il dit que grâce à l’API de ce dernier, on peut automatiser les transferts de fichiers vers Atrium tout aussi facilement. Philippe s’interroge sur la question de l’authentification: sans certificats de groupe, auxquels la politique d’administration est généralement hostile, comment permettre à tout membre du groupe contrôle-commande de récupérer les binaires depuis un compte utilisateur unique sur une machine partagée ? Une solution possible, si les données ne sont pas secrètes, est d’autoriser un accès public sans authentification.

Il est intéressant de noter que ces problèmes d’authentification reviennent à chaque fois qu’on utilise une machine ou un compte utilisateur partagé, que ce soit pour faire des sauvegardes ou installer des logiciels. Il serait peut-être intéressant d’y trouver une solution de long terme générale au lieu de toujours procéder au cas par cas.

Un avantage à l’utilisation d’Atrium est son contrôle d’accès plus fin, qui permet par exemple de distinguer entre versions de développement privées et versions de production publiques.

On peut envisager d’automatiser l’export de binaires depuis Gitlab vers la solution choisie via les hooks de déploiement de l’intégration continue.

Café LoOPS sur Vue.js

Les deux derniers cafés LoOPS ont été consacrés au framework Javascript Vue.js et à l’outil d’intégration continue TeamCity.

Le style était assez différent: le café sur Vue se rapprochait davantage d’un tutoriel expliquant comment utiliser le framework, celui sur TeamCity tenait plus de la description de l’outil. Il est intéressant de noter que le format préféré dépend des affinités de chacun.

Serge voulait savoir si l’IAS, qui ont de l’expérience d’Angular.js, ont émis des commentaires et déclarations d’intention concernant Vue. Les personnes présentes ne se rappellent de rien de tel.

La personne qui a effectué la présentation de Vue l’utilise de façon intensive dans ses développements. Il l’utilise essentiellement pour des besoins d’interface homme-machine généralistes (administration d’une infrastructure).

Est-ce que Vue pourrait intéresser PSPA ? Ce point sera discuté avec le contracteur quand on le connaîtra. Il est plus probable que PSPA utilise une combinaison de plusieurs technologies, intégrant outils d’interface hommes-machine généralistes et bibliothèques plus spécialisées dans la visualisation de données scientifiques (ex: D3.js).

Projet PSPA

Pour rappel, PSPA (Platform for Simulation of Particle Accelerators) est un projet qui vise à fournir une interface unifiée vers les nombreux logiciels de simulation utilisés lors de la mise au point d’accélérateurs de particules. L’idée est d’en finir avec les interfaces utilisateur incohérentes et les formats de données non documentés et incompatibles, en proposant une IHM et un bus de données unifié pour l’ensemble des outils concernés.

L’outil a été utilisé avec succès dans le cadre du projet PHIL, et le prochain défi auquel on va le consacrer est la source de rayonnement synchrotron compacte ThomX. Dans ce cadre, PSPA a récemment acquis la capacité de modéliser l’injection d’un paquet d’électrons dans un anneau de stockage et son mouvement au sein de ce dernier.

PSPA se présente à l’utilisateur via une interface web. Initialement, cette dernière avait été réalisée via le framework Wt, un générateur de code HTML/CSS dont l’API est similaire à celle de Qt. Mais le développeur qui s’occupait initialement de l’interface de PSPA, Laurent Garnier, a quitté le LAL depuis, et plus personne dans le projet PSPA n’a les connaissances et la volonté requis pour régler les problèmes ergonomiques de l’IHM.

Face au manque de compétences internes du LAL et à la difficulté de trouver des collaborateurs extérieurs, une solution à base de sous-traitance a finalement été choisie. Il a été prévu, dans ce cadre, de collaborer avec le sous-traitant sur la conception de l’interface et de recevoir des formations de ce dernier afin de pouvoir à terme reprendre la maintenance de PSPA en main au LAL.  Le code source du front-end PSPA sera aussi libéré à terme.

Au-delà de cette gestion des compétences IHM, Antoine pense que cette réécriture sera aussi une bonne occasion de revoir l’architecture de PSPA, par exemple pour mieux séparer le front-end du back-end et mieux spécifier les interfaces logicielles entre ces composants.

Meltdown et Spectre

Le sujet des deux failles de sécurité qui ont défrayé la chronique en ce début d’année, Meltdown et Spectre a été brièvement évoqué.

Pour résumer, des défauts de conception dans les CPU modernes permettent à un attaquant qui peut exécuter du code sur une machine d’avoir un accès en lecture seule à des informations qui lui seraient normalement inaccessibles:

• L’attaque Meltdown permet à un processus non privilégié d’avoir accès aux données du noyau d’un système d’exploitation.
• Les attaques Spectre permettent à du code sensé être isolé du reste du système, par exemple qui s’exécute dans l’interpréteur Javascript d’un navigateur web, d’avoir accès aux données privées de son processus hôte, voire d’autres processus.

Ces failles proviennent de couches très basses du matériel (éxécution spéculative), donc la seule manière de les éliminer est de revoir la conception de ce dernier, ce qui prendra très longtems. En attendant, des solutions de contournement logiciel qui évitent d’utiliser la portion vulnérable du matériel ont été proposées.

Comme la spéculation est une optimisation de performance très importante dans les processeurs modernes, ces solutions ont un impact fort sur les chemins de code concernés: les patches pour Meltdown augmentent le coût d’un appel système, avec pour résultat des pertes de performances allant jusqu’à ~30% dans les applications qui font beaucoup d’appels système (ex: bases de données), ceux pour Spectre ont un coût en performance dans tout code qui effectue des branchements (if / else, méthodes virtuelles…), dont l’impact exact n’a pas encore été mesuré précisément.

Tout programme qui stocke des données secrètes et exécute du code potentiellement malveillant est concerné par cette faille. Cela inclut par exemple les noyaux des systèmes d’exploitation, les hyperviseurs (hôtes de machine virtuelles), les navigateurs web, et les interpréteurs de code en général (Python, Java…).

Les administrateurs systèmes du LAL et du CERN sont actuellement très affairés à déployer les correctifs de sécurité pour ces failles dans les services centraux. En parallèle, d’autres administrateurs de systèmes plus spécialisés s’interrogent: l’impact de performances de ces patches se justifie-t-il vraiment sur des systèmes qui ne manipulent pas de données secrètes et n’exécutent que du code de confiance, comme les machines d’acquisition de données des expériences ? Ne devrait-on pas les désactiver au cas par cas sur les systèmes où ils ne sont pas nécessaires ?