Introduction
Si vous me suivez sur les réseaux sociaux, vous avez peut-être vu que j’étais pour la troisième fois au FOSDEM (Free and Open Source Software Developers’ European Meeting).
Contrairement aux années précédentes, cette fois-ci, le trajet et l’hôtel n’étaient pas payés par mon employeur. J’ai décidé d’y aller sur mes fonds propres. Pas de pression (Belgique, pression, bières, vous l’avez ? ok ok j’arrête, pas taper) donc pour faire de la veille techno intense et faire un récap’ professionnel.
Enfin ça, c’était le plan.
Mais je devrais mieux me connaitre que ça pour savoir que finalement, j’ai passé deux jours aussi intenses que les années précédentes (voire plus ?).
Je sirote donc ce qu’il me reste de club maté pour vous écrire ces quelques lignes (ahahah ~13000 signes).
Vendredi soir, FOSDEM before FOSDEM
Preuve qu’on finit toujours par apprendre de ses erreurs, je suis arrivé “tôt” cette année. J’étais au centre de Bruxelles à 18h, ce qui m’a permis de prendre quelques bières avec deux groupes d’amis différents sans pour autant me coucher trop tard.
Car c’est beaucoup ça en fait le FOSDEM, des discussions autour d’une boisson froide (alcoolisée ou pas)
(mais souvent alcoolisée, et d’ailleurs ça me fait beaucoup réfléchir depuis quelques mois)
Samedi
Malgré une heure de coucher raisonnable (minuit et quelques), je n’ai pas réussi à aller voir le premier talk que je souhaitais voir (problématique dont je vais avoir besoin, pour le travail 🫣).
- Cache me if you can: P2P Image Sharing in Kubernetes with Spegel
En réalité, j’étais absorbé dans une intense discussion sur l’optimisation de clusters Ceph pendant le petit dej’ de l’hôtel (vraiment, aller au FOSDEM dans l’idée de ne pas bosser, c’est raté sur toute la ligne xD).
Mais j’irai voir le replay, car j’en ai eu de bons échos.
A new cgroup cpu.max.concurrency controller interface file
En revanche, j’étais à l’heure pour le talk suivant, qui était un lightning talk de Mathieu Desnoyers pour promouvoir une initiative visant à ajouter un nouveau type de cgroup.
L’idée principale est qu’aujourd’hui, surtout sur des machines baremetal pouvant avoir des centaines de cores, restreindre un container à une quantité donnée de cores par secondes n’a plus vraiment de sens, car cela peut correspondre à plein de cores pendant un très court instant ou alors un seul core pendant 1 seconde.
Un peu rude de commencer sur ça, mais le problème et la proposition de résolution était plutôt bien présentée. À suivre !
Bringing application containers to Incus
Ceux qui me connaissent savent que je suis un fan inconditionnel de LXC (j’ai écrit beaucoup d’articles sur ce sujet). Et même si j’ai peu creusé LXD (forké par la communauté en “Incus” après une décision controversée de Canonical), je suis les évolutions avec attention (j’avais d’ailleurs vu un talk à ce sujet au FOSDEM l’an dernier).
Cette année encore, j’ai aimé ce talk de Stéphane Graber. Il nous a parlé d’ajouter des containers applicatifs (au format OCI) dans Incus.
En effet, un des avantages d’Incus est de pouvoir gérer plusieurs types de workloads, containers LXC ou machines virtuelles plus classiques, mais il n’y avait pas de support explicite des containers au format OCI (“Docker” par abus de langage). L’idée principale derrière cet ajout réside dans le constat qu’aujourd’hui beaucoup d’applications sont livrées dans ce format et que les repackager pour Incus est un travail fastidieux (et inutile), et que faire du nested-Docker n’a pas vraiment de sens.
En soit, il ne devait pas manquer grand-chose puisque LXC supporte déjà les images au format OCI depuis un moment. C’est d’ailleurs le hack que j’utilise dans mon article phare (comment je me la pète ?!) :
A tester :)
Tags pour moi-même : umami et skopeo
Writing a kubernetes controller… But in Rust
Pour le troll (mes collègues comprendront) et un peu par curiosité, je suis resté pour le talk d’après vantant les mérites de Rust pour écrire un controller dans Kubernetes plutôt que Golang (ou autre, d’ailleurs).
J’ai trouvé le discours de Danil un peu confus et j’ai eu du mal à suivre, car j’étais très loin et les exemples de codes étaient en darkmode… L’exemple ci dessous n’est même pas le pire, certains bout de code dans les slides suivantes, en rouge sur noir, étaient illisibles, même en zoomant :
Note aux aspirants/aspirantes speakers, dans un amphi éclairé, le darkmode, c’est illisible.
State of Checkpoint/Restore in Kubernetes
Un des talks que je VOULAIS voir, et au final, j’ai été un peu déçu (pas par le speaker, vous allez comprendre). Là encore, c’était la suite d’un sujet de talk que j’avais vu ailleurs.
Pour celles et ceux qui ne voient pas trop de quoi on parle, il s’agit de mettre en place le tooling nécessaire pour être capable de migrer des containers à chaud d’une machine à une autre.
Ça nécessite d’abord de pouvoir prendre une “photo” de l’état du container (le checkpoint) avant migration (aussi bien les metadatas que les données du container), puis de savoir restaurer cet état à l’identique sur une autre machine (restore).
Ça peut aussi servir à sauvegarder des containers, ou à faire du forensics dessus en cas d’attaque par exemple.
TL;DR : ça n’a quasiment pas avancé.
Et Adrian Reber nous a expliqué pourquoi. Une grande partie de la communauté Kubernetes considère (à tort à mon avis) que les containers qui tournent dans Kubernetes sont stateless et si un hôte meurt et qu’on doit redémarrer tout ses containers, ce n’est pas grave.
Or, il y a de très nombreux contre-exemples à cette affirmation. C’est faux pour les bases de données ou les bus de messages (même si on peut contourner le problème avec du clustering), les containers stateless mais qui ont des longues connexions qui se font trancher en cas de kill, ou même les traitements de machine learning qui peuvent durer des heures.
Pour tous ces usages, tuer le container pour le redémarrer ailleurs est potentiellement pénible / disruptif pour l’utilisateur (pas forcément final). Et je suis un peu chafouin qu’on en soit qu’à passer en Beta (2024) et qu’il n’y ait pas encore de support dans kubectl de cette techno réclamée depuis 2015 !!!
Immutable All the Way Down - using System Extensions to ship Kubernetes
Ce talk de Thilo Fromm n’était pas du tout ce à quoi je m’attendais. À vrai dire, je ne savais pas à quoi m’attendre (je n’avais pas lu l’abstract, je ponçais juste ma chaise d’amphi).
J’ai découvert les SysExt (petit nom des System Extensions), un outil permettant de créer des systèmes d’exploitation immutables et composables, compatible avec tous les OS du moment qu’on a systemd (le speaker a utilisé Flatcar et Kubernetes).
C’était assez inattendu et intéressant. Et malgré quelques glitchs pendant les diverses démos, le speaker a bien su montrer les intérêts de l’outil, à savoir la composabilité du système, la possibilité de décorréler OS sous-jacent et application (separation of concerns), les mises à jour à chaud.
Je ne suis pas sûr d’avoir un usecase intéressant en tête, mais c’était une bonne découverte.
Tag pour moi-même : kured
14 years of systemd
La tête bien farcie de talks (certains ont été omis, car je n’ai pas grand-chose à dire dessus), grande pause.
Puis, probablement LE talk de la journée.
Dans le plus grand amphi du FOSDEM et une salle comble, Lennart Poettering, le créateur de systemd, a fait un petit retour sur la création et les perspectives pour le futur d’un des outils les plus controversés dans Linux.
Let’s have a look back at the tumultuous beginnings, how we became what we are now, and let’s talk a bit the perspective for the future, what systemd is supposed to be in the eyes of its developers – and what it shouldn’t be.
C’était un talk intéressant même si on n’est pas toujours d’accord avec cette personnalité clivante. Il permettait de remettre un peu de contexte et d’avoir le point de vue de Lennart lui-même, en opposition aux seuls discours pas toujours très objectifs à l’encontre de systemd, mais qui sont les seuls qu’on entend sur les réseaux sociaux.
Seul bémol, je n’ai pas pu aller voir le talk sur metal-stack.io et je n’ai pas eu le courage d’aller voir autre chose après ça.
- On prem Kubernetes at scale with metal-stack.io
Fin de journée autour de quelques gaufres et boissons.
Dimanche
Réveil prévu un peu plus tôt dimanche, de manière à arriver à l’heure pour les premiers talks en “room observability” :
- Discovering the Magic Behind OpenTelemetry Instrumentation
Spoiler alert: je n’ai quand même pas réussi à arriver à l’heure xD, donc j’en ai profité pour aller faire un tour de loot stickers/goodies.
Prometheus Version 3
J’ai réellement commencé la journée avec un talk que je n’étais pas spécialement pressé de voir, parce que j’étais persuadé (vu le changelog) qu’il n’y avait rien de bien foufou (et donc rien à apprendre) dans cette version majeure de Prometheus.
Et finalement, c’était plutôt intéressant, mais plus par curiosité que par le niveau technique.
De ce que je comprends après ce talk, cette v3 (majeure donc) était surtout l’occasion de faire passer tous les “breaking changes” accumulé au fil des ans, ainsi que toutes les améliorations cachées derrière des features flags qui auraient pu être activée par défaut, mais ne l’étaient pas par souci de rétro compatibilité. Ca dit quelque chose de la gouvernance du projet.
À revoir, si vous dans l’écosystème Prom.
The performance impact of auto-instrumentation
Mon talk préféré de la (courte) journée. A l’aide de “benchs” (même s’il refuse de parler de ces tests empiriques de cette façon), James Belchamber nous a montré les ordres de grandeurs qu’on peut espérer voir à propos de l’impact de l’instrumentation manuelle et automatique sur divers types de codes.
Le talk était vraiment très agréable et le speaker n’a malheureusement pas pu finir (trop de contenu).
Les take aways :
Zero code distributed traces for any programming langage
Le talk au résultat inattendu du jour, pour moi, c’était celui-ci. Le titre était prometteur : pourquoi faire de l’observabilité auto-instrumentée pour tous les langages sans efforts, je signe tout de suite (au travail…).
Ce talk était une présentation de Beyla, un outil de Grafana Labs, dont le but est d’auto-instrumenter tout type de code à l’aide d’eBPF.
On sent la hype venir et malheureusement, ça n’est au final que ça : de la hype.
J’ai aimé le côté candide du talk, les difficultés rencontrées ont été expliquées sans tabous, les limitations (nombreuses) explicitement listées.
Mais clairement, ça ne me donne pas envie de tester l’outil, et encore moins d’y participer.
L’ultime blague étant justement que les speakers ont lourdement insisté sur le fait qu’il fallait qu’on vienne contribuer, ET qu’ils voulaient refiler le bébé à la CNCF.
Comme un grand singe a dit :
Je ne dirais pas que c’est un échec, je dirais que ça n’a pas marché.
This is the end
Après ça, j’ai décidé d’aller manger des frites bien méritées et la pause est passée très vite. Tellement vite qu’il était finalement temps de récupérer ma valise et d’aller à la gare pour le retour.
Pas de chance, j’aurais aimé voir quelques autres talks, mais pour pouvoir rentrer à une heure raisonnable sur Nantes (car, j’enchaine avec un déplacement pro), c’était impossible.
- Mastering Observability with SigNoz -> Open-Source Alternative for Metrics, Logs, and Traces
- The Art of Fleet-Wide Kubernetes Observability: 3 Core Strategies
Cette édition, j’ai l’impression d’avoir beaucoup plus profité des gens (des amis de longue date, des anciens collègues, des personnes qui connaissent mon blog, des amis/amies speakers, des bénévoles sur les stands, ou même des inconnus qui m’ont abordés au hasard des couloirs)
Notamment parce que :
- je suis arrivé “tôt” la veille
- je suis venu “de ma poche”, et pas pour le travail (mais si ça y ressemble beaucoup)
Je pense que ces deux points sont importants et à retenir. Je réalise que j’ai de la chance de pouvoir me payer ce genre de week-end sans trop y penser (tout le monde n’a pas cette chance), et que je devrais en profiter.
Pour finir, je vous laisse sur quelques photos en vrac de ce week-end (une fois de plus) mémorable.
