Oui, c'est ce que je pense aussi. La réposne d'Ethan, si on en a une.., sera négative d'après ce qu'a dit Marc Powell. Il faut bien voir que je n'ai pas sorti Shinken comme ça du jour au lendemain concernant les core dev. Ceci fait un petit moment que je leur présente les idées avec une preuve à l'appui qu'elles fonctionnent. Je me suis fait envoyer sur les roses à chaque essaie.
A un moment, il fallait faire un électrochoc, la mailing list me tendait les bras. Je pense qu'il est plus rapide de compléter Shinken que de reprendre ses idées et de les incorporer dans l'implémentation actuelle. J'ai peut être tord, mais qu'au moins les core dev prennent position et disent clairement ce qu'ils en pensent. S'ils disent qu'ils sont partant et motivés pour m'aider à prendre les idées et les incorporer au Nagios actuel, c'est parti.
Je pense qu'Ethan est très orienté XI (close source) en ce moment. On ne le reverra pas sur la mailing avant un moment, et les annonces qui tendent à lui couper l'herbe sous le pied des modules close source qu'il voulaient pour XI ne vont pas lui plaire. Et c'est exactement ce qu'est cette annonce.
Avec une bonne utilisation des techniques d'héritage de conf, c'est parfaitement gérable (et pas que les modèles, mais vraiment toutes les techniques d'héritages, notamment l'implicite).
On pourrait penser à une possibiltié de conf en base, mais lâcher la possibilité d'avoir sa conf en fichier plat est dangereuse. C'est pratique un fichier plat :)
Pour l'Arbiter oui, pour l'instant il est seul, mais je vais régler ça.
Pour le découpage scheduler/poller j'y ais beaucoup pensé dernièrement. Pour de toute petites sondes rapides, on a plus de perf si on se passe de poller. En effet, 60% de perfs consommées les sont dans ... l'échange des checks (et des exports de status vers le broker) avec des sondes qui ne font rien (juste sleep). Mais avec des sondes lourdes (du perl codé à la va-vite par exemple) là c'est la fin, il te faut plusieurs pollers par scheduler. Donc lorsque la charge des sondes devient plus importante que celle du transfert, pouvoir augmenter le nombre de poller est intéressant.
Ce découpage est violent par rapport à Nagios oui. Mais à mon goût il fallait séparer les rôles. C'est bien plus facile à maintenir comme ça je trouve. Ca fait un peu plus composants qui travaillent ensemble, et non pas un gros bloc monolithique.
- La plupart sont très liés à Nagios, à part le poller/reactionner qui peut être utilisé pour lancer n'importe quoi en fait le tant que ce qui nous intéresse est un code retour et l'output. L'API est basique et basée sur du Pyro, mais on pourrait imaginer de placer la dépendance à un service comme optionnelle si d'autres veulent utiliser autre chose.
-Oui, un plugin ça attend. C'est pour ça qu'il faut en lancer plein. Mais même s'ils attendent 80% de leur temps, ils travaillent un jour tout de même :) Donc tu as tout de même une limite sur le nombre que tu peux lancer en parallèle. Ce nombre est complexe a déterminer suivant le tyype de sonde (certains sont très lent, d'autres non), ce qui complexifie le nombre que tu va autoriser à être en parallèle. J'essais justement de déterminer le niveau de "charge" du poller pour qu'il soit au max, mais pas plus.
On pourrait intégrer les plugins les plus courants dans le code du poller, suivant ce qu'il devrait lancer il utiliserait tel code natif python plutôt que de faire un exec(). Je n'ia pas encore trouvé de méthode facile çà utiliser pour l'utilisateur (il "décrit" le plugin à utilsier dans la conf de sa commande? On se base sur une reconnaissance de la commande en expression régulière?)
Le fait de dédier des pollers je ne suis pas sûr, car un poller pourrait avoir plusieurs types de workers (c'est eux qui on un nombre de process lancés en parallèles), donc le mix pourrait se faire là, sans trop de chanboulement.
Pour la compatibilité avec les plugins, c'est totale, pas la moindre inquiétude là dessus. La force de Nagios réside dans ses plugins, pas l'ordonnanceur. Pour la conf, Shinken vise pour l'instant du 90% de compatibiltié. Si il est inclu dans la branche officielle de Nagios, je viserais le 100% forcément, même si de nombreuses options sont inutiles.
J'ai préféré ne pas répondre à cet email là, le lâché de troll aussi tôt dans une discussion, ce n'est pas bon :)
D'ailleurs pour pouvez remarquer dans un des derniers emails l'apparition d'un sondage et sur une possibilité de choix originale qui je suis sûr à bien aidé à réveillé le débat :)
Le choix est 80% sur mon goût pour le Python, 20% pour ses qualités intrinsèques.
Les capacités dynamiques de Python comme le rajout de propriétés d'un objet à chaud ou bien le fait de pouvoir vérifier qu'il a bien une propriété particulière est très pratique dans le contexte de Nagios (la configuration utilise des principes d'héritages d'objet, donc ça colle parfaitement aux capacités du langage).
Si tu rajoutes un module Python comme Pyro pour les objets distribués d'un très grande qualité, le fait que le langage a très bonne publicité et que je me retrouve dans le "zen de python" (les grands principes du langage), le choix était fait.
Il me semble que Erlang aurait pu être utilisé car l'architecture est très distribuée, mais j'ai préféré parier sur un compromis plus reconnu et avec une plus grande communauté.
Perl il y en a dans beaucoup de sondes utilisées par Nagios, et encore, mais pas par le daemon ni par le CGI. Je pense que le choix de PHP est pertinent. L'ancienne interface est très lourde en terme de maintenance de code. Pour l'instant Ninja est un très bon remplaçant de l'interface standard de Nagios, mais elle ne permet pas de gérer la configuration comme le fait Centreon par exemple. Regardons comment elle va évoluer, mais félicitons les auteurs, car c'est déjà un pas dans la bonne direction :)
[^] # Re: Tentative de réponse à la question
Posté par Jean Gabes (site web personnel) . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 2.
A un moment, il fallait faire un électrochoc, la mailing list me tendait les bras. Je pense qu'il est plus rapide de compléter Shinken que de reprendre ses idées et de les incorporer dans l'implémentation actuelle. J'ai peut être tord, mais qu'au moins les core dev prennent position et disent clairement ce qu'ils en pensent. S'ils disent qu'ils sont partant et motivés pour m'aider à prendre les idées et les incorporer au Nagios actuel, c'est parti.
Je pense qu'Ethan est très orienté XI (close source) en ce moment. On ne le reverra pas sur la mailing avant un moment, et les annonces qui tendent à lui couper l'herbe sous le pied des modules close source qu'il voulaient pour XI ne vont pas lui plaire. Et c'est exactement ce qu'est cette annonce.
[^] # Re: Enfin !
Posté par Jean Gabes (site web personnel) . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 3.
[^] # Re: Vachement gore
Posté par Jean Gabes (site web personnel) . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 1.
On pourrait penser à une possibiltié de conf en base, mais lâcher la possibilité d'avoir sa conf en fichier plat est dangereuse. C'est pratique un fichier plat :)
Pour l'Arbiter oui, pour l'instant il est seul, mais je vais régler ça.
Pour le découpage scheduler/poller j'y ais beaucoup pensé dernièrement. Pour de toute petites sondes rapides, on a plus de perf si on se passe de poller. En effet, 60% de perfs consommées les sont dans ... l'échange des checks (et des exports de status vers le broker) avec des sondes qui ne font rien (juste sleep). Mais avec des sondes lourdes (du perl codé à la va-vite par exemple) là c'est la fin, il te faut plusieurs pollers par scheduler. Donc lorsque la charge des sondes devient plus importante que celle du transfert, pouvoir augmenter le nombre de poller est intéressant.
Ce découpage est violent par rapport à Nagios oui. Mais à mon goût il fallait séparer les rôles. C'est bien plus facile à maintenir comme ça je trouve. Ca fait un peu plus composants qui travaillent ensemble, et non pas un gros bloc monolithique.
Sinon merci :)
[^] # Re: questions (réutilisations, multiplexage, compatibilité)
Posté par Jean Gabes (site web personnel) . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 1.
-Oui, un plugin ça attend. C'est pour ça qu'il faut en lancer plein. Mais même s'ils attendent 80% de leur temps, ils travaillent un jour tout de même :) Donc tu as tout de même une limite sur le nombre que tu peux lancer en parallèle. Ce nombre est complexe a déterminer suivant le tyype de sonde (certains sont très lent, d'autres non), ce qui complexifie le nombre que tu va autoriser à être en parallèle. J'essais justement de déterminer le niveau de "charge" du poller pour qu'il soit au max, mais pas plus.
On pourrait intégrer les plugins les plus courants dans le code du poller, suivant ce qu'il devrait lancer il utiliserait tel code natif python plutôt que de faire un exec(). Je n'ia pas encore trouvé de méthode facile çà utiliser pour l'utilisateur (il "décrit" le plugin à utilsier dans la conf de sa commande? On se base sur une reconnaissance de la commande en expression régulière?)
Le fait de dédier des pollers je ne suis pas sûr, car un poller pourrait avoir plusieurs types de workers (c'est eux qui on un nombre de process lancés en parallèles), donc le mix pourrait se faire là, sans trop de chanboulement.
Pour la compatibilité avec les plugins, c'est totale, pas la moindre inquiétude là dessus. La force de Nagios réside dans ses plugins, pas l'ordonnanceur. Pour la conf, Shinken vise pour l'instant du 90% de compatibiltié. Si il est inclu dans la branche officielle de Nagios, je viserais le 100% forcément, même si de nombreuses options sont inutiles.
[^] # Re: URLs
Posté par Jean Gabes (site web personnel) . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 1.
D'ailleurs pour pouvez remarquer dans un des derniers emails l'apparition d'un sondage et sur une possibilité de choix originale qui je suis sûr à bien aidé à réveillé le débat :)
[^] # Re: Belle initiative
Posté par Jean Gabes (site web personnel) . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 6.
Le choix est 80% sur mon goût pour le Python, 20% pour ses qualités intrinsèques.
Les capacités dynamiques de Python comme le rajout de propriétés d'un objet à chaud ou bien le fait de pouvoir vérifier qu'il a bien une propriété particulière est très pratique dans le contexte de Nagios (la configuration utilise des principes d'héritages d'objet, donc ça colle parfaitement aux capacités du langage).
Si tu rajoutes un module Python comme Pyro pour les objets distribués d'un très grande qualité, le fait que le langage a très bonne publicité et que je me retrouve dans le "zen de python" (les grands principes du langage), le choix était fait.
Il me semble que Erlang aurait pu être utilisé car l'architecture est très distribuée, mais j'ai préféré parier sur un compromis plus reconnu et avec une plus grande communauté.
[^] # Re: URLs
Posté par Jean Gabes (site web personnel) . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 6.
https://sourceforge.net/mailarchive/message.php?msg_name=6f8(...)
[^] # Re: Bien mais... bah bravo quand même :)
Posté par Jean Gabes (site web personnel) . En réponse au journal Nagios devcon #1 : Niiiiiinnnnjjjjjjaaaaaaa. Évalué à 3.