Jean Gabes a écrit 467 commentaires

Oui c'est le nom des katanas les plus coupants. Ceci illustre la fonctionnalité première le l'outil : découper la configuration pour la dispatcher sur des daemons.

Pour moi un projet qui peux devenir close source et donc enlever des libertés aux utilisateurs n'est pas un choix qui me convient. Si d'autre le font c'est leur choix, mais le code que j'écris n'enlèvera pas des libertés aux utilisateurs. Ensuite c'est sujet à discutions bien sûr vu que personne n'est d'accord sur ce point lorsque l'on parle de licences...

Oui mais là c'est un problème d'interprétation, donc jugement et compagnie.

Merci beaucoup pour ces éclaircissements.

3.1 : non, en aucun cas.
3.2 : la documentation dans un autre répertorie est issue de Nagios, donc elle est en GPLv2.
3.3 : vu que pas de code en commun, pas de soucis (enfin c'est ce que j'aurais cru au départ...).

Ah non, si ça part dans du close source là il courrir longtemps. Non, si ça fait du GPL à l'ancienne mode Nagios (donc toute les inovations dans le code libre, et non dans la partie privatrice) là oui.

Je suis si mauvais que ça en communication? Je savais que le marketing ce n'était pas pour moi, mais à ce point là :p

Sincèrement je n'avais pas l'impression d'être si odieux avec eux, juste de répondre avec mon propre style (un poil décalé parfois...).

Bref, passons.

S'il faut que je passe en GPLv2 bah j'y passerai, mais je me demande juste ce qui va se passer après.

*Nagios le réintègre et joue le jeu de l'open source : ok, je signe de suite!
*il l'intègre, vire quelques parties pour en remettre d'autres sous licence fermée : là je vais être moins d'accord...

En fait je n'ai pas grand chose à perdre au final avec le passage GPLv2. Je ne vois pas de sénarios où la communauté y perds en fait (sans le cas numéro2, je fork le code python pour remettre les parties supprimées...).

Très intéressant, merci ça y ressemble bien en effet.

S'il pleure mais que c'est justifié, après tout il aura eu raison. Après pour une réintégration pure et simple le problème c'est que ce que propose Shinken en open est ce qu'il voulait proposer en closed source.

S'il est d'accord pour que Nagios reste ouvert avec le code Shinken, passer de AGPL à GPL sera un petit sacrifice que je consentirai sûrement à faire.

Pour les attaques personnelles je n'ai fait que répondre. Peut être pas avec le bon style en effet, mais les attaques étaient vraiment grosses et blessantes pour certaines.

Pour les cris à la censure : ok je fais quoi sinon le dire? Me taire et ne pas avertir sur où va ce projet?

Pour la chaise : le style était pas le bon, je te l'accorde, mais j'ai réellement failli faire tomber mon café ce matin devant le mail.

Mais merci des remarques, j'essayai de lever le pied sur mon style sur les retours, je vais en faire d'avantage.

Pour l'inspiration oui c'est de l'inspiration du nom de macros qu'il a utilisé et que j'ai utilisé pour le nom de mes classes.

Oui mais à la limite je ne suis pas contre justement. Si j'ai toujours accès après aux sources pour améliorer la version communautaire ça ne me pose pas de soucis de ne pas diriger le projet en fait.

Par contre s'il souhaite juste prendre le projet sans moi, bah il peut s'il passe en GPLv2 (mais même en AGPL non?) en effet. reste à voir ce qu'il en fait ensuite en fait. S'il traite le code comme il est en train de le faire du projet open source, là je serai assez contre.

Bref, si je peux garder la AGPL pour que les utilisateurs aient un maximum de droit, je préfère bien sûr.

Ce qui me dérange n'est pas qu'il cherche à rentabiliser son outil. C'est même son droit le plus total. Non, ce qui me dérange est comment il s'y prends : en utilisant la communauté comme un simple argument marketing, et en orientant le développement vers sa solution privatrice, sans rien retourner au moteur initial.

C'est un modèle Open Core. C'est légal, mais pas très moral sachant que la communauté a été la première force de Nagios.

De plus jusqu'à maintenant Shinken avait pour vocation de réintégrer Nagios, même si son auteur l'aurait utilisé pour sa solution privatrice. Mais au moins la communauté pouvait encore le faire évoluer. En effet, les propositions d'évolutions sur Nagios ne sont pas écoutées. Ceci pose un léger soucis.

Faire un lien avec Icinga pourquoi pas, je discute beaucoup avec eux ces temps-ci en effet. Reste à voir comment se ferra un tel rapprochement. L'aspect <techniquement compatible> c'est facile, en majorité déjà fait même si Shinken propose des notions de haut niveau pas encore fournies par Icinga web (leur module web, principale force d'Icinga).

Par contre je ne chercherai pas à me couper d'autres partenaires comme Centreon par exemple. car j'adore Centreon que j'utilise tout de même tous les jours :)

J'ai pleinement conscience de la division des forces, c'est bien pour ça que je mettais ma fierté de côté et que je demandais une inclusion dans Nagios canal historique. Mais vu que ce n'est pas possible, je suis bien obligé de proposer un nouveau choix à la communauté. J'espère seulement proposé une migration si facile que ceci ne posera pas de problème à tous les administrateurs.

La version 0.2 de Shinken va justement être orientée vers l'industrialisation et la facilité de mise en place de l'outil. D'ailleurs ceux qui vont voir les sources doivent mieux s'y retrouver depuis le code de la semaine dernière.

Shinken devait être la solution pour Nagios afin de lutter efficacement contre Zenoss et Zabbix. J'espère qu'il le sera, et que ce ne sera qu'un simple nom de paquet à changer lors de la mise en place de notre cher outil de supervision.

Oh oui, j'en suis particulièrement conscient. Je vais passer une annonce sur la mailing list en priorité haute.

Bon, il fallait s'y attendre un peu, j'ai eu une réponse officielle (enfin ça y ressemble bien) de la part de la société derrière Nagios par l'intermédiaire un post twitter de la directrice de communication http://twitter.com/motherofnagios

Si on oublie le message précédent qui lance encore un FUD sur la marque Nagios à propos du plus grand regroupement de la communauté allemande qui a eu lieu il y a quelques temps, on peut en tirer comme conclusion que, seedcamp étant là pour trouver les nouvelles idées pour le projet Nagios, Shinken n'a même pas le droit de présence (dommage, la communauté aurait peu être eu un avis différent qui sait) dans l'environnement Nagios.

Pas de chance, il est tout de même là.

Le projet Shinken ne va donc plus chercher à intégrer le projet Nagios, vu que ce dernier n'en veut pas. Je vais faire en sorte de garder une compatibilité maximale pour ceux qui souhaite migrer, mais on peut désormais considérer Shinken comme un Fork de Nagios à part entière.

Et vive Darwin surtout :)

Ah oui c'est vrai, mais revenir sur la syntaxe des exceptions en as fait que le code devient tout de suite moins joli. Je reconnais que ce n'est pas un critère de premier ordre, mais moi j'aime bien ne pas avoir à détourner le regard quand je regarde mon code :p

Si quelqu'un se lance dans une migration vers 2.5 pourquoi pas, mais bon, dès que debian sera passé à une Python un peu plus à jour, on pourra revenir à une version plus sympathique.

Par contre là on parle pour l'écosystème GNU/Linux. Quelqu'un sait quelles sont les versions de Python classiques (entrendre en standard) pour les autres Unix (genre les Unix dont les noms commencent par un A ou un H)?

En effet, je suis la même personne, mais Shinken était déjà en cours depuis bien avant le soucis de droit sur le nom nagios entre ex-nagios-fr.org et Nagios Enterprise.

Shinken n'est pas un projet renégat. Il est arrivé comme un proof of concept non public pendant plusieurs mois. Le but était à l'époque de corriger les bugs que j'avais vu dans Nagios lorsque j'ai rédigé un livre dessus. Il y avait des problèmes de conceptions lorsqu'on arrivait à vouloir monter des environnements distribués grosso-modo.

Déjà auteur de plusieurs patchs pour Nagios (même après le début de Shinken d'ailleurs), j'avais présenté ces idées en offlist, mais il me fallait des preuves du bien fondé de mes idées (Pool de process pour les performances, division des processus pour la partie distribution).

Toujours en off, j'ai développé le proof of concept et j'ai présenté les idées pour intégrations en C dans Nagios. Ce développement était donc purement technique. N'ayant aucune réponse j'ai continué le développement. Je suis arrivé à un point où il était plus facile de mettre dans le proof of concept ce qui manquait de Nagios, plutôt que de continuer à vouloir extraire les idées pour les porter en C.

Là j'ai encore proposé une idée, mais plus originale, toujours en off : inclure le code du proof of concept dans une branche de développement. Toujours sans réponses (c'est une habitude sur le projet Nagios...), je relance ma proposition sur la mailing list (décembre, soit plus de 6 mois après le début du code finalement).

Là les réactions ont étés vives, mais au moins il y a eu réaction! sauf de l'auteur par contre.

C'est après cette histoire qu'est arrivée celle entre nagios-fr.org et l'auteur de Nagios. Histoire qui ne portait d'ailleurs pas du tout sur Shinken, mais sur Icinga, autre Fork de Nagios, soutenu par une société allemande.

Je ne compte plus les mails que j'ai envoyé en off à l'auteur de Nagios avant et après la proposition sur la mailing list pour savoir ce qu'il en pensait, mais je dois tomber dans son filtre spam vu que je n'ai jamais eu une seule réponse.

Là encore j'essaie d'intégrer le projet Nagios officiel en participant au concours seedcamp alors que le projet Shinken est déjà bien parti et pourrait s'en passer. Et devinez quoi? Et bien oui, le concours est soumis à modération, et pour l'instant ma proposition n'est pas encore validée pour ce concours alors que d'autres le sont.

Il ne faut pas oublier que Shinken propose à l'heure actuelle des fonctionnalités qui ne devraient être présentes que dans quelques mois dans la version privatrice de Nagios. Ceci explique peut être cela après tout. Ça devient un peu politique, mais ce n'est pas pour me ravir, bien au contraire car je ne suis pas si doué que ça à ce petit jeu.

Hé bien ça tombe bien, voici l'appel en Python dans le code :
self.process = subprocess.Popen(shlex.split(self.command), stdout=subprocess.PIPE, stderr=subprocess.PIPE, close_fds=True)

Je trouve le module subprocess bien plus pratique à utiliser que les vieux popen (qui sont de toute manière toujours présent) :)

Le journal en question n'était-il pas un pauvre troll qui a peur devant la montée en puissance de Python au cours de ces dernières années? Mais bon un troll reste un troll, il ne cherche pas à argumenter après tout.

En fait c'est déjà le cas pour la partie module du daemon broker qui fait l'export des données (par exemple en MySQL ou Oracle). Ce n'est pas encore documenté par contre, mais les exemples de modules sont très simples à comprendre.

Ce type de module devrait arriver dans les autres daemons également. On peut imaginer par exemple un module pour l'Arbiter, qui est chargé de lire la configuration, module qui lirait la configuration en base plutôt qu'en fichier plat par exemple.

Un autre exemple de module serait pour le daemon poller qui est chargé de lancer les sondes. Un module pourrait être un python embarqué comme il existe du Perl embarqué pour Nagios, ou bien un module natif NRPE qui aurait de meilleures performances que de faire un popen par exemple.

Mais pour ça, il faut que je définisse comment les modules sont intégrés à ces daemons. Je prends toute aide/expérience sur ce point, comme sur tous les autres d'ailleurs.

Ah? Je ne crois pas que mon avis sur Python ait tellement changé. Peut être que je me suis mal exprimé.

En fait le but de Shinken au début était exactement celui-là : faire un test rapide en Python, puis porter en C.

Mais en prenant un peu de recul face à la facilité de porter Nagios en Python je me suis demandé quel serait le meilleur langage pour Nagios justement. C'est un ordonnanceur (donc gérer des dates et temps) qui lance des sondes (popen sur un script ou exécutable) et qui réagit au résultat (autre popen).
Est-ce une problématique bas niveau? Je ne pense pas. Gérer le temps n'est pas un problème de calcul très violent, surtout en utilisant un peu de cache sur les calculs lourd (5 lignes...). Le popen? Et bien le module pour en Python est très efficace et pratique à utiliser.

Je ne dit pas que c'était une erreur de coder Nagios en C il y a 10ans, car c'était le meilleur compromis pour avoir une grosse communauté. Mais maintenant? Le Python s'est fortement démocratisé (il n'y a qu'à voir les stats du langage sur ohloh) et offre une maintenabilité bien supérieure au C, sans pourtant sacrifier les performances.

La migration est problématique, j'en ait conscience, et ce problème ne sera peu être jamais résolu que par une bête guerre de projet. Au pire j'échoue, mais le coup de pied au c%l du projet Nagios sera déjà ça de pris, car au moins désormais il avance un petit peu avec seedcamp par exemple.

Si maintenant quelqu'un pense le contraire et porte mes idées en C pour le cœur, je ne vais pas lui jeter les pierres, bien au contraire. Mais je ne ferai pas ce travail moi même tout simplement. Je sais qu'une partie de ce que j'ai proposé est en cours de réalisation depuis quelques temps (le pool de process). Mais ce n'est qu'une partie de ce que Shinken apporte. Et au vues du temps que ceci prends, je pense avoir raison de rester sur Python.

L'avenir nous dira qui a raison. Au pire, en cas d'échec de ma part, j'aurais fait bouger Nagios et je me serait bien marré en codant en Python.

Il ne fonctionne pas. Tout comme avec la version standard sur RedHat5 et assimilé. Mais même pour cette dernière, la mise en place de Python 2.6 est facile.

La résistance a été forte, c'est un fait. Le soutient aussi, même si moins affiché. Par contre une personne n'a jamais donnée son avis, que ce soit officiellement ou non : l'auteur de Nagios tout simplement. C'est l'occasion pour lui d'accepter ce qu'on lui offre. Il a presque tout à y gagner en fait. C'est pour ça qu'il y a des chances que ceci réussisse.

C'est en effet la AGPL qui s'applique (sauf pour la documentation récupéré de Nagios, donc GPLv2). En fait je me suis mis du point de vue client qui se voit surveillé par un prestataire qui utilise l'outil : c'est libre il le sait, mais il n'a pas accès au code utilisé pour le superviser si c'est du GPLv3 standard. Le client doit avoir accès à ça, d'où la AGPL.

Ensuite ce n'est pas rédhibitoire car ceci ne concerne que le coeur de l'application, pas les sondes de supervision. Hors dans la quasi totalité des cas, c'est elles qui font la vraie plus value du prestataire avec l'organisation qui va autour.

Ah bah oui tout simplement.

Ah merci, car moi non plus je ne sais pas comment faire. Je suis en train de proposer une dépêche, quelqu'un va bien m'aider pour les liens.

Ah oui pour la dépêche, je vais rédiger et surtout compléter un peu plus alors.

Le choix du Python est en fait une heureuse rencontre : je connaissais ce langage que j'apprécie beaucoup, et au début Shinken était un proof of concept pour Nagios, donc il me fallait un langage où on puisse coder vite (et bien), quitte à reporter le code en C plus tard dans Nagios.

Il s'est révélé ensuite qu'il était plus simple (et efficace) de terminer le proof of concept avec ce qui lui manquait de Nagios que le contraire.

Pour les performances en fait l'architecture permet d'avoir une distribution de la charge très facile, mais c'est surtout l'utilisation du module multiprocessing de Python >= 2.6 qui permet de gagner en performances tout simplement. Nagios passe une grande partie de son temps à forker/écrire des fichiers plats. Deux problèmes réglés avec ce module. D'où de meilleures performances tout simplement, pas de secret ici.

Par contre je n'ai pas compris les numéros entre crochets. Ce n'est pas la méthode habituelle pour les liens?

J'ai oublié le nom de code de cette première version : Anemic Alligator. Ceci représente bien le potentiel de l'outil, mais qui a encore besoin d'un peu de temps pour arriver à maturité.