Mon expérience en tant que mentoré LFX pour Chaos Mesh
Cette page a été traduite par PageTurner AI (bêta). Non approuvée officiellement par le projet. Vous avez trouvé une erreur ? Signaler un problème →
Je suis étudiant en master d'ingénierie logicielle à l'Université de Nanjing. Mes recherches portent sur DevOps, qui présente des liens intrinsèques avec le chaos engineering et l'observabilité. Pour m'impliquer dans la communauté open source, approfondir ma compréhension de Kubernetes et découvrir le quotidien des infrastructures, j'ai postulé au programme de mentorat CNCF LFX à l'automne 2021 pour travailler sur le projet Chaos Mesh.
Processus de candidature
Fin août, j'ai terminé un stage orienté business. Comme prévu, j'ai réalisé que le domaine commercial ne m'intéressait guère. En revanche, j'ai toujours eu une passion pour les technologies d'infrastructure. Par hasard, j'ai découvert le projet Chaos Mesh dans le cadre du mentorat LFX de la CNCF. J'ai vu là une formidable opportunité de contribuer à un projet open source, un rêve que je caressais depuis longtemps. Ayant les compétences techniques requises, j'ai soumis mon CV juste avant la date limite.
Trois jours plus tard, j'ai reçu un email d'entretien de mon mentor. Dans le cadre de cette sélection, il m'a confié une petite mission : développer un mini-node-exporter exposant des métriques Prometheus et les affichant dans un tableau de bord Grafana. Je devais également déployer cet outil, ainsi que Prometheus et Grafana configurés, sur une plateforme Kubernetes. La conception et l'implémentation se sont déroulées sans accroc. La seule difficulté a été d'écrire la configuration YAML du tableau de bord Grafana pour le déploiement Kubernetes. Après de nombreuses recherches documentaires et expérimentations, j'ai finalement résolu ce problème.
Le 30 août, j'ai eu la chance d'apprendre que j'avais réussi l'entretien. Lors de la réunion individuelle avec mon mentor, nous avons simplement évoqué ma familiarité avec Kubernetes et d'autres technologies, les tâches principales et quelques échéances clés. J'ai aussi exprimé certaines préoccupations, comme la pression de mon projet de laboratoire qui pourrait affecter l'avancement du mentorat, ou les directives de conception des métriques. Mon mentor a très bien compris mes inquiétudes et y a répondu.
Déroulement du projet
Le projet pour lequel j'avais candidaté s'intitulait Monitoring Metrics about Chaos Mesh. Son objectif était d'améliorer l'observabilité du système Chaos Mesh en collectant des métriques et en fournissant un tableau de bord Grafana.
Durant les deux premières semaines, je me suis familiarisé avec les processus métier et certains détails du code de Chaos Mesh. Les deux semaines suivantes, j'ai rédigé le document de conception pour structurer toutes les métriques et méthodes de collecte. Pendant cette période, j'ai étudié les bonnes pratiques de conception des métriques et rencontré mon mentor pour comprendre les détails de la proposition et certaines logiques du code.
La plupart de ces métriques étaient relativement simples à collecter, nécessitant seulement des requêtes basiques sur des objets de base de données, des objets k8s ou de simples comptages. Cependant, certaines métriques spécifiques se sont révélées plus complexes. Par exemple, il fallait interroger des données en exécutant des commandes dans l'espace de noms réseau du conteneur correspondant, ou requêter tous les conteneurs d'un démon via trois runtimes différents, ou encore collecter des données sur la communication entre client et serveur gRPC.
Ces tâches m'étaient étrangères. J'ai donc dû solliciter régulièrement le support technique de mon mentor, qui s'est toujours montré très réactif. Son expertise approfondie dans ce domaine m'a particulièrement impressionné. Guidé par ses conseils, j'ai finalement pu finaliser le document RFC pour ma conception. Par la suite, afin de suivre mon travail, j'ai créé une issue de suivi.
Cependant, durant la phase de codage qui a suivi, j'ai rencontré divers problèmes. Avec le recul, j'ai constaté que beaucoup auraient pu être résolus en amont. Voici donc quelques conseils que j'ai tirés de cette expérience :
Garder un esprit critique. En acceptant la proposition, j'avais suggéré une solution pour chaque métrique de manière intuitive, mais j'avais négligé des questions fondamentales : ces métriques sont-elles nécessaires ? Existe-t-il une meilleure solution disponible ? Ces interrogations de base auraient dû être traitées lors de la phase de proposition, mais elles se sont propagées à l'implémentation. Par exemple, lors de la soumission du RFC, mon mentor et les relecteurs m'ont rappelé que certaines métriques étaient déjà implémentées dans la bibliothèque controller-runtime. Quand j'ai travaillé sur les métriques liées au BPM, un relecteur m'a posé une question similaire. C'est alors que j'ai réalisé que je n'y avais jamais prêté attention.
Communiquer continuellement. Savoir communiquer efficacement est crucial dans ce type de mentorat. J'ai appris plusieurs leçons à ce sujet, mais la plus marquante est qu'il vaut mieux proposer des options avant de solliciter des conseils. Lorsque vous devez demander de l'aide, présentez plusieurs pistes de solution à votre interlocuteur. Même si ces options ne sont pas valides, elles reflètent votre réflexion. Ainsi, sauf si vous n'avez vraiment aucune idée après avoir creusé le sujet, évitez de soumettre des questions trop ouvertes.
Comprendre l'open source. C'était ma première expérience concrète avec l'open source. Comparé au travail en entreprise, les différences sont notables. Voici quelques exemples :
-
La synchronisation d'information : Contrairement aux entreprises où la communication passe souvent par des réunions en présentiel, la plupart des échanges dans une communauté open source se concentrent sur les canaux Slack, les issues GitHub et les pull requests. Il est donc essentiel de documenter son travail pour tenir les autres membres informés. Durant les premières semaines, j'ai maintenu un document R&D en ligne par habitude. J'ai ensuite réalisé qu'il était préférable d'utiliser un Kanban ou une issue GitHub, évitant ainsi un coût de communication supplémentaire pour mon mentor.
Document R&D en ligne -
Des tests automatisés plus complets et rigoureux : Dans les entreprises, les tests automatisés se limitent souvent à l'analyse statique de code, aux tests unitaires et à de simples smoke tests, tandis que les tests manuels sont plus poussés. Mais dans les projets open source, le pipeline automatisé inclut des cas de test plus détaillés et complets : tests d'intégration, tests end-to-end, vérification de licences, etc. La qualité et la sécurité du code soumis sont ainsi contrôlées en amont.
-
La relecture de code : De nombreuses personnes participent à vos revues de code, et le processus peut durer longtemps. Contrairement au monde professionnel, il n'y a pas de relecteurs dédiés dans une communauté open source. Il peut s'agir d'utilisateurs, de mainteneurs ou d'autres membres de la communauté, assignés ou volontaires, ce qui explique en partie la durée des revues.
Après le projet
J'ai vécu une expérience formidable durant ces 12 semaines. J'ai approfondi ma compréhension de Kubernetes, des CRD et de l'observabilité. J'ai aussi pris conscience de mes lacunes concernant l'amélioration de la structure du code, les bases de Linux et les technologies de conteneurisation. Il reste encore beaucoup à apprendre !
Parallèlement, en raison de la pression imprévue de mon projet de laboratoire, je n'ai pas pu consacrer autant de temps que souhaité au mentorat. Je n'ai même pas pu finaliser la conception de la partie Grafana dans les délais. Je compte absolument poursuivre ce travail et espère le mener à bien pour conclure ce projet de manière satisfaisante.
Je tiens à remercier mon mentor @STRRL. Durant ce mentorat, j'ai rencontré de nombreux défis techniques comme des opérations Git complexes, des solutions pour résoudre des dépendances circulaires, ou la recherche de l'interface d'exécution pour CRI-O. Sans la patience et les conseils avisés de mon mentor, il m'aurait été difficile de surmonter ces problématiques techniques inhabituelles. Je souhaite également remercier les mainteneurs de Chaos Mesh pour leurs relectures de code, ainsi que le programme CNCF LFX Mentorship qui offre une formidable plateforme pour celles et ceux souhaitant s'impliquer dans la communauté open source.
Pour conclure, je formule ce vœu : que chaque étudiant désireux de rejoindre la communauté open source puisse franchir le premier pas grâce au programme LFX Mentorship !