Interview d’Andreas Ericsson, auteur de Naemon

Posted by Olivier Jan on 13 Nov 2013 in Communauté, Interviews, Nagios | 1 comment

Nous l’avons annoncé récemment, Nagios a encore été forké. À ce rythme, ça va devenir une mode. « Alors toi aussi, t’as forké Nagios ? » C’est la question, pas la seule, que je suis allé posé à Andreas Ericsson, dernier Nagios forker en date. En route pour la Suède donc… Non je déconne, on a pas encore les moyens à monitoring-fr; c’est donc par e-mail interposé que j’ai posé ces quelques questions à l’auteur de Naemon et également le dernier contributeur historique qui restait à la barre du développement de Nagios.

N’étant pas traducteur professionnel, loin s’en faut, vous trouverez l’original des questions/réponses en anglais en pièce jointe de cette interview et des [brackets] dans le texte indique une note du traducteur ou le mot original en anglais. J’espère avoir évité la faute suprême; à savoir le contre sens. N’hésitez pas à signaler toute erreur de traduction par les moyens habituels.

Un naturellement mais ça va mieux en le disant grand merci à Andreas pour la disponibilité et la réactivité dont il a fait preuve pour cette interview. Les personnes qui le connaissent n’en seront pas surpris. Assez de bla, place à l’interview.

L’interview

Pouvez-vous nous parler un peu de vous-même ? Là où vous habitez, votre travail, ce que vous pensez important de présenter à la communauté française

J’ai grandi dans une petite ville en Suède, mais ai déménagé à Göteborg (qui reste une petite ville par rapport aux grandes villes dans le monde) quand j’avais 19 ans. J’ai commencé à programmer quand j’avais 7 ans. Une fois à l’école secondaire, quelques amis et moi-même avons écrit un jeu qui a écroulé tout le réseau scolaire. Je continue de ressentir une certaine fierté pour ce fait 🙂

En 2000, j’ai commencé le parachutisme et suis entré par l’intermédiaire de ce fabuleux hobby en contact avec mon ami Johannes, qui m’a engagé pour faire un travail de conseil en développement chez Op5. J’ai fait un assez bon travail apparemment, car un mois plus tard, j’étais à un entretien d’embauche avec le fondateurs de Op5. Je pense qu’ils avaient déjà décidé d’avance de m’embaucher, car en raison d’un incident malheureux avec un chat incontinent à Barcelone (où j’avais passé mes vacances juste avant l’entetien d’embauche), je suis venu à l’entrevue vêtu d’un sarong dégoulinant, une tunique et des sandales sales. Tout le reste puait le chat « pisseux », comme si l’un des nombreux chats errants d’Espagne était allé dans ma chambre et s’était soulagé dans ma valise deux heures avant que l’avion ne décolle.

Quel est, a été votre implication, rôle dans le projet Nagios Core ?

J’ai découvert Nagios en 2004 quand j’ai commencé mon travail chez Op5. Une de mes responsabilités était de faire en sorte que Nagios fonctionne bien pour les clients d’Op5 (nous avions environ trois à l’époque, d’autant que je me souvienne). C’est donc ce que j’ai fait, et j’ai envoyé un tas de patchs et quelques idées pour des fonctionnalités futures. À l’époque, Ethan était actif et c’était plutôt amusant de travailler avec lui, bien qu’il n’aimait pas partager son code avant d’en être satisfait lui-même.

Le projet Nagios a commencé à stagner réellement aux alentours de 2007, juste après la sortie de Nagios 3. Ethan a décrété que le projet était fini d’un point de vue fonctionnel et que le développement se limiterait dorénavant aux corrections de bugs. Vu qu’il y avait près d’une centaine de patchs différents éparpillés sur les différentes listes de diffusion, j’avais le pressentiment que je n’étais pas le seul à être en désaccord avec cette affirmation. J’ai commencé à m’occuper des patchs en assurant à minima une sorte de feedback aux contributeurs. Un grand nombre de correctifs, patchs ont été rejetés soit parce qu’ils ne répondaient qu’à une problématique ne représentant qu’un très faible pourcentage de la base d’utilisateurs, soit parce qu’ils provoquaient une rétro-incompatibilité [backwards-incompatibility] ou simplement parce qu’ils étaient carrément « foireux ». Mais certains ont été « approuvés » et je les ai mis de côté. La plupart de ceux approuvés ont été incorporés tôt ou plus tard à Nagios. Cela m’a permis de gagner un début de crédibilité en tant que développeur dans la communauté.

En 2008, Ethan a complètement disparu du projet et du coup aucun nouveau code n’a pu être incorporé. En 2009, un groupe d’Allemands en a eu marre de tout ça. En effet, ils avaient de bons patches dont ils avaient vraiment besoin pour supporter leurs clients. Du coup, Netways a forké Nagios. Je n’ai pas vraiment approuvé la manière dont ils l’ont fait à l’époque (beaucoup trop de polémique). Mais avec le recul, je pense que Nagios Enterprises et Netways se sont livrés à beaucoup de manœuvres politiques et que le reste d’entre nous n’a pas vu le tableau d’ensemble.

Quoi qu’il en soit, à la suite de tout ça, Ethan s’est rendu compte qu’il devait faire quelque chose
pour que le projet continue. Du coup, Ton Voon, Thomas Guyot- Sionnest et mon humble personne ont été approchés pour devenir développeurs du noyau (core) et membres du Nagios Community Advisory Board. La première partie développement était super car je pouvais valider des correctifs directement dans Nagios au lieu de les garder dans mon propre référentiel. La deuxième partie s’est juste avéré être de la poudre aux yeux [marsh gas] puisque nous n’avons jamais été consultés sur tout ce qui touche à Nagios. La même année, j’ai rencontré Ton et Ethan à Bolzano lors d’une conférence. J’ai commencé à rédiger les améliorations que je voulais mettre en œuvre dans le code de base. Personne n’a rien trouvé à redire à ça. Je me suis donc décidé à obtenir du temps de la part d’Op5 pour faire ce travail.

Dans le même temps, j’ai partagé ces plans d’amélioration avec Jean Gabès, qui était très remonté par le fait qu’un patch qu’il avait soumis à Nagios n’ai pas été accepté. Nous avons eu une discussion électronique et je lui ai dit qu’il serait préférable d’utiliser des processus de travail [worker] pour exécuter les contrôles plutôt que de le faire à la façon Nagios 3. Jean a construit un proof-of-concept de cette idée. Ça s’est avéré tellement amusant et pertinent à faire qu’il en a sorti un véritable projet et l’a appelé Shinken.

En 2011, j’ai commencé à travailler sur les changements qui permettraient de transformer Nagios 3 en un Nagios 4 exceptionnellement performant. En 2012, tout était terminé. Pendant cette période, j’étais de plus en plus reconnu comme « The Nagios developer », surtout qu’Ethan n’était visible nulle part. En regardant l’histoire des commits à partir de 2010 environ, je ne peux que reconnaître cet état de fait.

Pourquoi avez-vous décidé de quitter le projet ?

Je n’ai pas décidé de quitter le projet. Je me suis suis fait viré. Après la Nagios World Conference North America cette année, Ethan s’est approché de moi alors que j’étais assis dans le bar en attendant mon vol de retour et m’a accusé de sciemment et volontairement saboter la sortie de Nagios 4. la raison en était un patch que j’avais soumis et qui a planté le builds des CGIs. Le correctif n’a pas pris plus de 30 secondes pour être appliqué. Il a pourtant juré que ses développeurs avaient passé une journée entière à travailler dessus et il était sérieusement bouleversé. Il a également été très contrarié que le département marketing d’Op5 ait utilisé le fait que la majorité du code de Nagios 4 ait été écrit par moi (94,5% pour être précis) dans leur stratégie marketing. Je crois que Nagios Enterprises a perdu quelques clients à cause de ça.

Mes tentatives de le convaincre que ces deux faits sont mutuellement exclusifs n’ont pas fonctionné. Il n’y a aucun intérêt pour moi à sortir quelque chose qui ne fonctionne pas correctement tout en faisant la promotion sur le fait que c’est moi qui l’ai codé. C’est tombé dans l’oreille d’un sourd. Il ne souhaitait plus écouter et m’a dit qu’à partir de maintenant je devais soumettre mes patchs à la liste Nagios developers comme tout le monde.

En aparté, je pourrais ajouter que les listes de diffusion on été fermées quelques jours avant la conférence et que tout a été déplacé dans un forum modéré à la place. C’est là que Ethan voulait que je soumettes mes patchs. Plusieurs développeurs d’Op5 l’ont fait. Le résultat a été que Eric Stanley [employé de Nagios Enterprise] apparaissait alors comme l’auteur des patchs soumis par les développeurs Op5. Je ne crois pas personnellement qu’Eric l’a fait exprès (et s’il l’a fait, je suis raisonnablement sûr que ce ne sont pas ses manières à lui). Cela signifie par contre que Nagios entreprises a décidé d’exclure toute personne étrangère à son sein des bénéfices d’avoir travaillé sur le code de Nagios. Ethan veut faire faire tout le travail par d’autres personnes mais veut en tirer tous les avantages.

Inutile de préciser que ce n’est pas la façon dont un projet Open Source doit fonctionner. Et ce n’est certainement pas un projet auquel je souhaite contribuer. Je ne suis pas sûr de ce que qui se serait passé s’il ne m’avait pas mis à la porte, mais la direction que Nagios prend n’est pas celle avec laquelle je suis en accord. Et jusqu’à un certain point, j’aurais commencé mon propre projet à un moment donné de toute façon.

Pourquoi un nouveau fork, pourquoi ne pas rejoindre une équipe ayant déjà forké (Icinga, Shinken…)?

Bonne question. Il y a plusieurs raisons.

Je n’ai pas voulu rejoindre Shinken parce que je suis un fervent croyant que les applications qui sont système intensives [heavy-duty system] doivent être rédigés dans le langage le plus efficace possible et ensuite maintenues si simples qu’elles ne peuvent pas plantées tout en s’interfaçant correctement avec d’autres systèmes qui peuvent être écrits dans n’importe quel languge qui plaîra à leur auteur. Je ne suis pas aussi à l’aise avec Python que je le suis avec C, et les tests de performance montrent que Naemon bat Shinken en terme de nombre de contrôles exécutés.

Je n’ai pas voulu rejoindre Icinga, principalement parce qu’ils construisent beaucoup sur IDOutils. Personnellement, je pense qu’IDOutils est une mauvais technologie doté d’un schéma de base de données qui est tout sauf clair. J’aurais voulu l’abandonner aussi vite que possible. Ça aurait été un problème pour Netways qui dirige le projet Icinga de sorte que nous aurions probablement couru au devant de problèmes dès le début.

Ce sont les deux seuls projets que j’ai considéré mais la vraie raison est certainement que je ne souhaite plus suivre le projet de quelqu’un d’autre désormais mais préfère construire le mien et voir ce qui se passe. Je suis très fatigué de toute ces conneries politiques qui ont accompagné ma récente sortie de Nagios et je ne veux pas revivre ça. La seule façon que cela n’arrive plus passe par la création d’un nouveau projet en tentant d’y associer les personnes en qui j’ai confiance dans l’excellence technique (bien au dessus de la valeur du marché). Jusqu’à présent, je crois que j’ai réussi à faire exactement ça puisque Sven Nierlein (auteur de mod_gearman et Thruk et un « exceptionnel gars laid-back » [une traduction quelqu’un ?] a accepté de se joindre au projet. Tout comme Robin Sonerfors, qui est un proche ami à l’endroit où je travaille. Un Américain nommé Dan Wittenberg a également offert de l’aide, et vu qu’il opère des réseaux beaucoup trop grands pour ne supporter autre chose que de l’excellence technique, j’ai la ferme conviction que nous sommes sur la bonne voie.

Quels sont ou seront les principales différences entre Naemon et les autres solutions comme Nagios, Shinken, Icinga pour n’en nommer que quelques-unes?

Naemon sera, au moins au début, concentrer sur l’essentiel, pas le superflu [bells and whistles]. Nous allons construire un produit de base qui sera si stable, performant et facile à intégrer avec autres choses qu’il lui sera possible de résister à la légendaire attaque nucléaire (n’essayez pas ça à la maison quand même, ce n’est pas bon pour vous).

Je n’ai aucun intérêt pour les interfaces utilisateurs ou de nouvelles façons d’afficher des graphiques. J’ai par contre de l’intérêt à rendre ça possible facilement pour les autres de sorte que n’importe qui puisse tester, télécharger et que le meilleur projet l’emporte. Nameon devrait aussi permettre aux entreprises de construire des extensions au-dessus de lui qu’ils n’auront pas nécessairement besoin de partager avec le monde entier. Ceci crée une opportunité d’affaires qui repose uniquement sur la concurrence et la meilleure utilisation des ressources disponibles.

Quels sont vos principaux objectifs pour Naemon ?

Comme pour tout programme que j’écris: stabilité, performance, extensibilité.
Je veux le garder aussi petit que possible et construire des interfaces [API] qui permettent aux autres de construire plus de choses à travers celles-ci. Je ne peux pas, ne veux pas et ne construirai pas tout moi-même. Ce serait stupide et égoïste. Je suis très bon dans la construction de noyaux évolutifs et scalables et je suis très mauvais dans la conception d’interfaces utilisateurs.

Quel est votre modèe d’affaires, si il y en un de prévu; pour Naemon ? souscriptions, version entreprise, support payant… ?

Il n’existe pas de modèle d’affaires. Naemon est libre (comme la bière et la parole). Je finirais peut-être par une liste de vœux sur Amazon, la mise en place d’un bouton Paypal « faire un don si vous voulez » ou quelque chose de similaire mais il n’y a aucun intérêt commercial direct dans Naemon. J’imagine que les entreprises vont vouloir exploiter ceci pour le vendre à leur clients et je les invite à le faire. J’espère qu’elles sauront partager certains de leurs projets avec le reste de la communauté ou qu’elles m’inviteront à des conférences où je pourrais boire un peu, beaucoup, mais ce n’est pas obligatoire. Personne n’a à payer pour utiliser Nameon.

Quelle place voulez-vous donner dans le projet Nameon à la communauté ?

Je ne suis pas sûr de ce que vous entendez par cette question mais je voudrais que Naemon devienne le meilleur Core, supérieur à toutess les autres solutions de surveillance réseau. Je voudrais que les développeurs et utilisateurs imaginent des choses à faire avec auxquelles je n’ai même jamais pensé. C’est généralement un très bon marqueur d’une excellente conception lorsque les gens prennent votre programme et font avec des choses extraordinaires jamais envisagées. Vous savez que vous avez fait quelque chose de vraiment, vraiment bien.

Êtes-vous ouvert aux contributions extérieures, prêt à les encourager?

Certainement. J’ai déjà pris des correctifs de certains gars en Islande et j’espère qu’ils continueront d’envoyer leurs trucs. Je vais aussi prendre les correctifs qui seront en adéquation avec la vision que nous avons pour Naemon, tant qu’ils n’ajoutent pas de code dégueulasse ou qu’il cassent la rétro compatibilité.

Pouvez-vous nous donner une feuille de route pour les prochaines versions, même dans les grandes lignes?

Oui et non. Je peux vous donner une vision et des étapes qui, je crois, jalonnent la route vers cette vision.

Dans l’avenir, je voudrais surtout que Naemon soit piloté par les événements [event-driven]. Les hôtes et les services doivent pouvoir être ajoutés ou supprimés à la volée, et des jeux de règles devraient pouvoir être appliqués aux résultats qu’ils envoient en se basant sur les données historisées.

Pour ce faire, nous aurons besoin d’addons qui peuvent se déclencher en même temps que le scheduler et qui commencent à faire des choses de leur côté. C’est pourquoi la possibilité d’exécuter des programmes complémentaires contrôlés par le scheduler [scheduler-controlled helper daemons] sera la première fonctionnalité que nous allons développer. Pour faciliter cela, nous devons construire un mécanisme de type « drop-dir » [sans traduction] pour que les fichiers qui chargent et configurent ces programmes complémentaires puissent être juste déposés dans un répertoire pour rendre la gestion des choses faciles avec les paquets RPM et Puppet.

Ensuite, nous allons étendre le module « NERD radio » et l’interface du gestionnaire de requête [query handler] afin de rendre l’extraction des informations de Nameon par des applications tierces plus facile. Elles pourront alors manipuler ces informations comme bon leur semble. Construire sur livestatus est tout aussi naturel puisque c’est rendu enfantin par le fait que Naemon support les modules « in-core » à l’instar des modules Apache qui peuvent être construits comme modules séparés ou directement intégrés au noyau.

Une fois que nous aurons ça en place, nous allons probablement faire une pause pour Noël et le Nouvel An puis nous envisagerons la modification des projets extérieurs existants pour qu’il tirent parti de ces nouvelles fonctionnalités. Le traitement des données de performance par PNP pourrait être beaucoup plus efficace par exemple et il ne sera pas difficile de le faire fonctionner encore mieux une fois que nous aurons les fonctionnalités décrites plus haut.

En supposant que nous ayons bien fait les choses lors de la conception des interfaces de base, nous pourrons alors passer à l’expérimentation de la supervision en auto-apprentissage. Jetez un œil sur Be développer la possibilié d’ajouter ou de détruire des objets à chaud, pendant le fonctionnement du programme. Il est probable que nous ayons besoin d’étendre les objets manipulés mais ça ne devrait vraiment pas poser problème.

Parmi les plus petites fonctionnalités à faire « parce que c’est mieux comme ça » se trouve la possibilité de modifier à chaud les paramètres du fichier principal de configuration. Mais pas tous cependant, il faut toujours être capable de trouver la socket du gestionnaires de requêtes [livestatus] par exemple et certaines variables n’ont de sens qu’au démarrage du programme de toute façon.

Je continue aussi de nourrir le rêve d’avoir des sets, kits de services dans Naemon où chacun pourrait configurer toute une série de contrôles en une seule fois. Des fournisseurs tels que Amazon, Google, divers hôtels sur le web et des fournisseurs de type « as a service » pourraient créer, maintenir et vendre leurs propres sets, kits complets avec les plugins, les valeurs de seuil suggérées afin que tout le monde puisse mettre en place son systèmes de supervision d’une manière beaucoup plus simple. Les personnes qui écrivent les appels vers l’API pour obtenir des données depuis le système étant aussi celles qui écrivent les contrôles feront donc en sorte que les deux fonctionnent.

Si cette dernière fonctionnalité est bien développée et vraiment utile, alors ce sera l’une des choses qui peuvent rendre Naemon vraiment, vraiment énorme [huge].

Un début d’analyse

Que vous compléterez en commentaire j’en suis sûr! Ce coup-ci, pour de vrai, Ethan se retrouve « seul » sur le projet Nagios. Seul avec ses employés et clients malgré tout, ce qui n’est pas négligeable. Mais seul sans sa communauté historique qui l’a menée, qu’il le reconnaisse ou non, là où il en est avec Nagios. Il peut remercier Andreas à ce propos pour le code de Nagios 4. Et s’il suit sa logique, le Core 4 devrait être le dernier à sortir, celui-ci étant considéré comme complet au niveau fonctionnel. Faut-il alors considérer le « parrain » mort et définitivement se tourner vers l’un de ses « rejetons ». le choix vous appartient mais j’ai personnellement déjà choisi ma route, sur laquelle je ne devrais plus croiser Nagios. So long old boy !