JDH : Bonjour Julien et merci de participer à cet entretien pour le Journal du hacker. Pour nos lecteurs qui ne te connaissent pas, peux-tu te présenter rapidement ?

Julien : De rien ! Je m'appelle Julien, j'ai 31 ans, et j'habite à Paris. Cela fait maintenant une quinzaine d'année que je développe des logiciels libres. J'ai eu le plaisir de travailler (entre autre) sur Debian, Emacs et awesome ces dernières années, et plus récemment sur OpenStack. Depuis quelques mois, je travaille chez Red Hat, en tant que Principal Software Engineer sur OpenStack justement. Je m'occupe de faire du développement upstream sur cette plate-forme cloud, principalement autour des projets Ceilometer, Aodh et Gnocchi.

JDH : Étant moi-même architecte système, je suis ton travail au sein du projet Openstack depuis un moment. Il est rare d'avoir le point de vue d'un participant aussi impliqué. Dans ce cadre, peux-tu nous faire un point général sur l'état actuel du projet puis nous détailler un peu tes activités au sein de ce projet ?

Julien : Le projet OpenStack a beaucoup grandi et changé depuis que j'ai commencé il y a 4 ans. Il est parti de quelques projets de base, comme Nova (compute), Swift (object storage), Cinder (volume), Keystone (identity) ou encore Neutron (network) qui sont considérés comme des briques de base pour une plate-forme de cloud-computing pour aboutir à une multitude d'autres projets.

Pendant un temps, l'inclusion des projets était soumis à une revue stricte du comité technique, mais depuis quelques mois les règles se sont grandement assouplies, et on assiste à beaucoup de projets liés au cloud-computing qui nous rejoignent.

Pour ma part, j'ai initié avec d'autres le projet Ceilometer en 2012, voué à gérer les métriques des plate-formes basées sur OpenStack. Notre but est de pouvoir collecter toutes les métriques, de les enregistrer pour analyse ultérieure. Nous avons également un module permettant le déclenchement d'actions basées sur des seuils (alarmes).

Le projet a grossi de manière monolithique et linéaire en terme de contribution les deux premières années, et j'en était le PTL (Project Technical Leader) pendant un an. Cette position de leader demandant beaucoup de temps en terme de paperasse et de gestion humaine, j'ai préféré laisser ma place pour pouvoir passer plus de temps à résoudre les challenges techniques que Ceilometer proposait.

J'ai initié le projet Gnocchi en 2014, et dont la première version stable (1.0.0) est sortie il y a quelques mois. C'est une base de données de série temporelle (timeseries en anglais) offrant une API REST et une forte capacité à monter en charge (scalability). C'était un développement nécessaire pour résoudre les problèmes liés à la quantité de stockage des métriques générées sur une plate-forme de cloud-computing ou des dizaines de milliers de machines virtuelles doivent être mesurées le plus souvent possible. Ce projet fonctionne aussi bien seul (standalone) que couplé avec Ceilometer et le reste d'OpenStack.

Plus récemment, j'ai initié la création d'Aodh, résultat de la sortie du code et des fonctionnalités de Ceilometer liées au déclenchement d'action sur seuil (alarming). C'est la suite du processus lancé avec Gnocchi, et qui pousse Ceilometer a être découpé en modules indépendants pouvant fonctionner ensemble - avec ou sans OpenStack. Il me semble que les fonctionnalités offertes par Ceilometer, Aodh et Gnocchi peuvent aussi être intéressantes pour des opérateurs d'infrastructure plus classiques. C'est pour cette raison, et pour avoir une architecture encore plus orientée service (SOA), que j'ai poussé le projet dans cette direction.

JDH : J'aimerais m'arrêter un instant sur Ceilometer. Je crois que cette solution était très attendue, en particulier par les fournisseurs d'infonuagique utilisant Openstack pour la facturation des ressources vendues à leurs clients. J'ai le souvenir d'un billet de blog où tu temoignais de la construction à grande vitesse de cette brique et de fonctionnalités qui n'auraient pas dû y être intégrées. Aujourd'hui avec Gnocchi et Aodh, qu'en est-il d'après toi et de la qualité de la brique Ceilometer et des programmes sur lesquels elle s'appuie ?

Julien : En effet, un des premiers cas d'utilisation de Ceilometer est lié à la possibilité d'obtenir des métriques pour les fournir à un outil de facturation. C'est un but maintenant atteint puisque des outils de facturation pour OpenStack existent et se basent sur Ceilometer, comme par exemple CloudKitty.

Cependant, d'autres cas d'usage sont très vite apparus, comme la possibilité de déclencher des alarmes. Cette fonctionnalité est nécessaire afin, par exemple, d'implémenter les fonctionnalités de mise à l'échelle automatique (auto-scaling) dont Heat a besoin. À l'époque, pour des raisons techniques et politiques il n'était pas possible d'implémenter cela dans un nouveau projet, et la fonctionnalité s'est retrouvée dans Ceilometer, puisqu'elle utilisait les métriques collectées et stockées par ce même Ceilometer.

Ceci dit, comme je le disais précédemment, cette fonctionnalité a maintenant son propre projet, Aodh. Les alarmes sont utilisées depuis plusieurs cycles dans des déploiements en production, et le projet Aodh de nouvelles fonctionnalités. Il permet de déclencher des actions sur seuils, et se trouve être une des rares solutions capable de tenir à grande échelle avec plusieurs milliers d'alarmes. Impossible de faire tourner un Nagios avec des millions d'instances pour récupérer des métriques et déclencher des alarmes, là où Ceilometer et Aodh n'ont aucun mal à répartir la charge nécessaire sur des dizaines de nœuds automatiquement.

D'un autre côté, Ceilometer a longtemps été décrié comme peu performant et compliqué à opérer, car son système de stockage des métriques était par défaut basé sur MongoDB. Clairement, le modèle de structure de données choisi n'était pas optimal pour ce que les utilisateurs voulaient faire de ces données.

C'est la raison pour laquelle j'ai commencé Gnocchi l'année dernière, qui est parfaitement designé pour ce cas d'utilisation. Il permet des temps d'accès linéaires aux métriques (complexité O(1)) et des temps d'accès rapides aux informations des ressources grâce à un index.

Aujourd'hui, avec 3 projets ayant chacun leur périmètre fonctionnel clairement défini - et qui peuvent fonctionner ensemble - Ceilometer, Aodh et Gnocchi ont finalement gommés les plus gros problèmes et défauts du projet initial.

JDH : Pour clore le sujet Openstack, une dernière question. Tu es un développeur Python de longue date, fervent utilisateur des tests logiciels et du développement piloté par les tests (TDD en anglais). Plusieurs billets sur ton blog mettent en avant l'importance de l'utilisation des tests dans le cycle de développement. Peux-tu nous en dire plus sur l'utilisation des tests au sein du projet Openstack et des prérequis en cette matière afin de pouvoir contribuer à Openstack ?

Julien : Je ne connais pas de projet aussi testé à tous les niveaux qu'OpenStack. Au début du projet, il y avait une vague couverture de tests, composée de quelques tests unitaires. À chaque nouvelle version, plein de nouvelle fonctionnalités étaient livrées, et il fallait croiser les doigts pour qu'elles fonctionnent. C'est le genre de chose qui est déjà limite acceptable, mais pourquoi pas. Le gros problème, c'est qu'il y avait également un bon nombre de régressions, et des choses qui fonctionnaient qui ne fonctionnaient plus comme avant. Souvent des cas particuliers auxquels les développeurs n'avaient pas pensé.

Le projet a alors changé de politique, et a décider de refuser tous les patches - nouvelle fonctionnalité ou correctif - qui n'implémentaient pas un minimum de tests unitaires prouvant leur fonctionnement. Très vite, les régressions ont disparues, et le nombre de bugs a largement diminué au fil des mois.

Puis sont venus les tests fonctionnels, avec le projet Tempest, qui lance une batterie de tests sur un déploiement OpenStack complet.

OpenStack possède maintenant une infrastructure complète de test, avec des opérateurs employés à plein temps pour la maintenir. Les développeurs sont en charge d'écrire les tests, et les opérateurs maintienent une architecture basée sur Gerrit, Zuul et Jenkins qui lancent la batterie de tests de chaque projet pour chaque proposition de patch.

Car oui, à chaque version d'un patch envoyé, un OpenStack complet est déployé dans une VM, et une batterie de milliers de tests unitaires et fonctionnels est lancé pour vérifier qu'aucune régression n'est possible.

Pour contribuer à OpenStack, savoir écrire un test unitaire est donc un pré-requis obligatoire - la politique sur les tests fonctionnels est un peu plus laxiste. Les outils sont des outils Python standards, il s'agit d'unittest pour le framework et de tox pour construire un environement virtuel (venv) et les lancer.

Il est également possible d'utiliser devstack pour déployer une plate-forme OpenStack sur une machine virtuelle et de lancer des tests fonctionnels. Cependant, étant donné que l'infrastructure du projet s'en charge également pour vous lors de la soumission du patch, il n'est pas obligatoire de le faire localement soi-même.

JDH : Les outils et les tests que tu écrits pour Openstack sont codés en Python, un langage qui jouit d'une popularité importante aujourd'hui. Tu sembles l'apprécier au-delà de la sphère professionnelle puisque tu as écrit un livre sur le sujet, The Hacker’s Guide To Python, que j'ai vraiment apprécié lire. Peux-tu nous expliquer ce qui t'a amené à Python, les principaux points forts que tu attribues à ce langage (rapidement) et quelle démarche t'a fait passer de programmeur à auteur ?

Julien : Je suis tombé un peu par hasard sur Python vers 2005. Je ne me souviens plus comment j'en ai entendu parlé, mais j'ai acheté un premier bouquin pour découvrir et commencer à jouer avec ce langage à cette époque. Mais à cette période, je n'ai pas trouvé de projet auquel contribuer ni de projet à commencer. Mon premier projet en Python fut rebuildd pour [Debian en 2007, un peu plus tard.

J'aime beaucoup Python pour sa simplicité, son orientation objet assez propre, sa facilité de déploiement et son écosystème bien fourni et open source. Une fois les bases maitrisées, il est très facile d'évoluer et s'en servir pour tout et n'importe quoi, car l'écosystème est bien fourni, et on trouve facilement des bibliothèques pour résoudre toute sorte de problème.

Je suis devenu auteur par hasard, en écrivant de temps en temps des billets sur mon blog au sujet de Python. Je me suis finalement rendu compte qu'après quelques années passées à développer en Python et à étudier l'intérieur de l'interpréteur (CPython), j'avais acquis bien des connaissances. En écrivant un billet sur les différents types de méthodes en Python - qui est encore aujourd'hui un des plus consultés sur mon blog - je me suis rendu compte que ce qui me semblait évident ne l'était pas pour beaucoup d'autres développeurs.

J'avais écris ce billet suite à mes milliers d'heures passés à faire des revues de code sur OpenStack. J'ai donc décidé de noter tous les points qui me semblaient poser problème aux développeurs et d'en faire un livre. Une compilation de ce que des années d'expérience m'ont appris à moi et aux autres développeurs que j'avais décidé d'interviewer dans ce livre.

JDH : J'ai été très intéressé par la publication de ton livre, à la fois par le sujet, mais aussi par la démarche adoptée. Tu t'es en effet auto-édité, ce qui me paraît aujourd'hui très pertinent. Est-ce un parti pris dès le début du projet ? As-tu recherché avant un éditeur ? Peux-tu nous en dire un peu plus à ce sujet ?

Julien : J'ai eu la chance tomber sur d'autres auteurs auto-édité, comme Nathan Barry – qui a même écrit un livre sur le sujet, Authority. C'est ce qui m'a convaincu que c'était possible, et qui m'a donné le déclic pour lancer ce projet.

J'ai commencé à écrire en août 2013, et j'ai lancé les premièrs entretiens avec d'autres développeurs à ce même moment. J'ai commencé par écrire le plan général du livre, puis rempli les pages de ce que je savais et de ce que je voulais écrire. J'ai réussi à terminer le livre début 2014, et la relecture ayant pris plus de temps que prévu, à le sortir seulement en mars 2014. J'ai écrit un rapport complet d'ailleurs à ce sujet sur mon blog, où j'explique plus en détail le processus, de l'écriture jusqu'au lancement.

Je n'ai pas cherché d'éditeur, bien que l'on m'ai proposé de me mettre en contact avec certains. L'idée de l'auto-édition m'ayant vraiment convaincu, j'ai préféré tenter l'aventure par moi-même, et je ne regrette pas. Il est vrai qu'il faut assumer les deux casquettes et gérer toute une partie supplémentaire, mais avec un minimum d'audience et l'aide d'Internet, tout est possible !

J'ai depuis été contacté par deux éditeurs, un chinois et un coréen, à qui j'ai cédé les droits d'éditions des traductions du livre. On peut donc acheter la version coréenne et la version chinoise de la première édition du livre.

Vu le succès, j'ai sorti une seconde édition en mai 2015, et il est probable qu'une troisième édition fasse son apparition en 2016.

JDH : Tu travailles aujourd'hui pour Red Hat, une société qui représente la réussite complète de l'utilisation du Logiciel Libre comme modèle commercial. Cette société fascine beaucoup dans notre communauté. Au niveau de ton expérience personnelle, quelques mots peut-être sur ton employeur actuel ?

Julien : Ça ne fait qu'un an que j'ai rejoint Red Hat (via l'acquisition d'eNovance, il faut considérer mon expérience comme encore quelque peu récente.

Ceci étant, Red Hat est vraiment une entreprise particulière à tous les niveaux. Il est difficile de se rendre compte de l'extérieur de l'ouverture de son organisation en interne, et de sa façon de fonctionner, réellement proche de celle du logiciel libre. Pour plus de détail, je vous encourage à lire The Open Organization, un livre que Jim Whitehurst (CEO de Red Hat) vient de publier et qui décrit la manière dont Red Hat est organisé. Mais pour résumer, c'est la méritocratie et l'absence d'organisation en silot qui fait la force de l'organisation et qui la place comme l'une des entreprises les plus innovantes.

Au final, j'ai la chance d'avoir une grande autonomie sur les projets sur lesquels je travaille avec mon équipe autour d'OpenStack, et de passer 100 % de mon temps à travailler upstream et à améliorer l'écosystème Python tout entier.