Nagios : l’auteur tente de museler sa communauté pour cause d’avoir été trop libre!!

Posted in Nagios by Nap on February 23, 2010

C’est un cri d’alarme de la communauté Nagios que je me permets de relayer ici. En effet, après une longue phase d’ignorance de cette communauté de la part de l’auteur de l’outil, nous sommes arrivés à un point qui semble sans retour : l’auteur tente de museler la communauté française pour avoir été trop ouverte!!

Revenons un peu sur les faits : lancé il y a plus de 10ans, Nagios est encore à l’heure actuelle l’outil de référence dans le monde de la supervision open source, et de sérieux concurrents comme Zabbix ou Zenoss commencent à lui faire de l’ombre. Dans le domaine de l’open source, et tout particulièrement celui de la supervision, la force des outils reposent sur leur communauté. Celle de Nagios a été fleurissante pendant des années. Cependant, depuis environs deux ans, l’absence de réponse de l’auteur principal aux propositions de cette communauté a légitimement irrité cette communauté, au point de voir fleurir un fork il y a environs un an, nommé Icinga.

Là où l’histoire se complexifie se passe dans la sphère économique des sociétés utilisant et supportant Nagios. Comme pour beaucoup de logiciels commençant à prendre de l’ampleur, après plus de 8 années dédiées au projet l’auteur a légitimement crée une société de support et d’intégration nommée “Nagios Enterprise” et qui a déposé le nom “Nagios”. Le fork “Icinga” est issu de membres de la communauté Nagios qui sont employés par “Netways”, société allemande qui fait elle aussi du support et de l’intégration de Nagios. Si la licence GPLv2 est respectée, l’opportunisme et le manque de fair-play de cette société a fortement irritée l’auteur de Nagios et le reste de la communauté qui est restée fidèle dans sa grande majorité au projet initial.

Cette histoire semble avoir malheureusement eu un effet collatéral : l’auteur de Nagios s’est retourné contre sa communauté et l’ouverture qui a permis ce fork en l’ignorant encore davantage si c’était encore possible, en ne répondant pas par exemple à des propositions d’amélioration substantielles de code. Dernier affront en date et non des moindres : l’auteur demande à ce que lui soit cédé l’enregistrement DNS nagios-fr.org afin qu’il puisse réunir une communauté plus “corporate” car celle-ci a parlée sur son site du projet open source, mais félon à ses yeux, Icinga. Posts qui de plus n’étaient pas particulièrement élogieux. Fork qui au final aura plus coupé l’auteur de sa communauté que simplement un projet en deux.

La coupe est pleine pour la communauté qui se veut aussi ouverte que les outils qu’elle défend. Dans logiciel Open Source, il y “free as in beer” mais aussi “free as in speech”. Olivier Jan, fondateur et leader de cette communauté francophone, a ainsi répondu [1] qu’il ne serait pas possible de se laisser dicter ce sur quoi la communauté pouvait parler. Pour ne pas risquer une hypothétique assignation en justice (pour protection de trademark), il a donc été décidé d’obtempérer à l’attaque en déplaçant le site de la communauté vers monitoring-fr et de donner nagios-fr.org à la société Nagios Enterprise une fois la migration finie.

C’est donc avec une lettre ouverte [2] au titre de “The nagios community wants to keep its open soul” que la communauté demande où ce projet se dirige, s’il sera toujours ouvert et respectueux des principes même des l’open source. Des questions se posent en effet sur la réelle volonté de laisser ce projet open source en gelant la partie GPL et en l’incluant dans une solution fermée (”Nagios XI” éditée et diffusée sous peu par Nagios Enterprise) qui sera vraisemblablement seule à évoluer dans les années à venir. La communauté demande encore comment elle est perçue, si elle a encore sa place et si elle est tenue de tenir sa langue dans sa bouche sous peine de poursuite judiciaire en cas de non respect de la sacro sainte parole corporate de Nagios Enterprise.

Cette communauté fortement active ces dernières année est supportrice de l’industrialisation et le support de Nagios par des sociétés de logiciels libres, mais à la condition de pouvoir garder son âme. Nous souhaitons tous que Nagios conserve son rang qui ne l’oublions pas lui a été apporté grâce au soutient de toute sa communauté et que le projet revienne à la “bonne époque” où les codeurs et personnes de bonne volontés avaient encore leur mots à dire face à la communication marketing.

Espérons que cette lettre ne restera pas lettre morte, car ceci finirait de creuser le gouffre qui sépare l’auteur de Nagios et sa communauté qui est la vraie force motrice du projet et ferait le nid d’un fork qui diviserait encore la communauté, et qui rajouterai encore des noms tabous sur les sites traitant de Nagios.

Toutes les personnes souhaitant apporter leur soutient à notre démarche peux le faire en votant sur http://ideas.nagios.org/a/dtd/22035-3955 (pas besoin d’avoir un compte) qui est le site des idées de Nagios.

[1] : http://www.nagios-fr.org/2010/02/accuse-nagios-fr-org-levez-vous/
[2] : https://sourceforge.net/mailarchive/forum.php?thread_name=20100223103544.9upjoc1mbogwwc4o%40intra.expertise-online.net&forum_name=nagios-devel

EDIT: l’auteur a répondu. Voir pour sa réponse.

Partie à trois : Python, __slots__ et metaclass

Posted in Programmation by Nap on February 15, 2010 3 Comments

Les langages dynamiques sont pratiques pour se frotter facilement à de nouveaux paradigmes de programmations. Aucune technique n’étant parfaite, l’aspect dynamique se paye.

Le prix à payer pour les langages dynamiques

Bien souvent on pense au coût CPU pour ces langages, mais cette ressource n’est pas la seule à prendre cher. Là où un accès à une structure est en 0(1) en C ou C++, il peut être plus élevé dans des langages où les propriétés des objets ne sont pas identiques entre les instances. Il en est de même pour la RAM : les objets pouvant avoir de nouvelles propriétés à chaud, leur accès se fait en vérifiant le dictionnaire __dict__ des objets. Le dictionnaire est fort simple:

class Test:
   def __init__(self, x, y):
      self.x = x
      self.y = y
point = Test(1, 2)
print ‘Initialement’, point.__dict__
point.z = 3
print ‘Apres’, point.__dict__

Donne :

Initialement {’y': 2, ‘x’: 1}
Apres {’y': 2, ‘x’: 1, ‘z’: 3}

C’est sympa, c’est dynamique. Mais ceci a un coût en Mémoire : ici nous avons un seul objet, mais si nous avons 1000 points, chacun aura son propre __dict__ indépendant, et surtout les chaînes ‘x’, ‘y’ et ‘z’ seront dupliquées dans chaque instance. Imaginons que nous avons 1000000 de points à conserver, la consommation de RAM va être de 176mo sur notre exemple (Python 2.6.4). Si nous prenons des classes avec des noms de propriétés plus grandes que ‘x’, on peut atteindre des sommets en terme de consommation de RAM pour finalement pas grand chose.

Le module guppy (disponible sur pypi de mémoire) peut être très pratique pour observer qui consomme de la RAM dans notre application. Son utilisation est fort simple :

from guppy import hpy
hp=hpy()
print hp.heap()

Sa sortie est (relativement) éloquente :

Partition of a set of 2024657 objects. Total size = 173885852 bytes.
Index  Count   %     Size   % Cumulative  % Kind (class / dict of class)
0 999999  49 135999864  78 135999864  78 dict of __main__.Test
1 999999  49 31999968  18 167999832  97 __main__.Test
2    127   0  4073248   2 172073080  99 list
3  10686   1   744928   0 172818008  99 str
4   5540   0   203368   0 173021376 100 tuple
5    347   0   115160   0 173136536 100 dict (no owner)
6   1539   0   104652   0 173241188 100 types.CodeType
7     64   0   100480   0 173341668 100 dict of module
8    175   0    94840   0 173436508 100 dict of type
9    194   0    86040   0 173522548 100 type

78% de la consommation mémoire est due aux __dict__ de nos points, les valeurs de ces instances consommant quant à elles 18%.

__slots__ : c’est les soldes pour Python

Lorsque l’on sait à l’avance quelles vont être les possibilités des noms de propriétés de nos instances, il peut être pratique de recourir à l’utilisation des __slots__. C’est un tuple dans la classe où les noms des propriétés vont être mises en commun pour toutes les instances de la classe. Attention, son utilisation est fort simple, mais elle limite certaines possibilités de Python par la suite, comme certains problèmes avec tout ce qui touche la sérialisation d’objet par exemple.

Si vous souhaitez l’utiliser, c’est fort simple, il suffit de rajouter le tuple à la classe si elle hérite d’object :

class Test(object):
   __slots__ = (’x', ‘y’, ‘z’)
   def __init__(self, x, y):
      self.x = x
      self.y = y

Si simple? Non en fait. le __slots__ va remplacer __dict__ qui va tout simplement disparaitre! Notre code va lamentablement échouer avec:

Initialement
Traceback (most recent call last):
File “test_slot.py”, line 10, in <module>
print ‘Initialement’, point.__dict__
AttributeError: ‘Test’ object has no attribute ‘__dict__’

Pour contourner cela, il suffit de rajouter __dict__ au slots:

class Test(object):
   __slots__ = (’__dict__’, ‘x’, ‘y’, ‘z’)
   def __init__(self, x, y):
      self.x = x
      self.y = y

On relance, la consommation passe à 47Mo. (Les gains sont encore plus importants avec des chaînes de plus d’un caractère :) ). Pour Shinken par exemple, avec 100000 services, j’étais à plus de 2Go de RAM consommée, avec les slots, je suis tombé à moins 50Mo environs…

Metaclass : une classe pour en modifier d’autres

En Python, on a déjà vu que les classes sont des objets comme les autres. Qui dit objet dit instanciation. Lors de cette instanciation, il peut être pratique de changer des choses à la volée. C’est justement le rôle des metaclass. C’est une classe qui va contrôler la création d’une autre. Elles peuvent être utilisées pour par exemple tracer automatiquement tous les appels de méthode d’une classe. Pour un tel exemple, voir sur http://www.afpy.org/Members/kerflyn/metaclass qui présente très bien cela.

On mixe le tout

Vous allez me dire: bon c’est bien les metaclass, mais c’est quoi le rapport avec les __slots__? Et bien c’est pratique lorsque l’on a beaucoup de propriétés dans une classe, comme par exemple Service ou Host de Shinken. Jusqu’à maintenant, lorsque je rajoutait une nouvelle propriété à ces classes, je rajoutais une ligne dans le tableau properties ou running_properties, mais je devais penser à rajouter ce même paramètre dans le tuple  __slots__ de la classe. Autant dire qu’une fois sur deux, j’oubliais. De plus, ça fait un gros pâté en début de classe, et je n’aime pas ça.

Je suis tombé sur http://code.activestate.com/recipes/435880/ qui présente comment générer automatiquement le tuple __slots__ pour ses classes en regardant tout simplement les variables fournies à __init__ (il semble créer d’ailleurs une liste qui doit être changée en tuple par l’interpréteur). Bon pour les Host et Service, il n’y a qu’un seul paramètre, un tableau de construction. Mais ça m’a donné l’idée d’adapter ce code pour qu’il utilise les tableaux properties et running_properties de mes classes qui contiennent toutes les propriétés de mes objets.

Edit : Merci à Bertrand Mathieu pour la simplification du code par set.

Ceci donne au final la classe AutoSlots suivante :

class AutoSlots(type):
   def __new__(cls, name, bases, dct):
      slots = dct.get(’__slots__’, set())
      #Now get properties from properties and running_properties
      if ‘properties’ in dct:
         slots.update((p for p in dct['properties']))
      if ‘running_properties’ in dct:
         lots.update((p for p in dct['running_properties']))
      dct['__slots__'] = tuple(slots)
      return type.__new__(cls, name, bases, dct)

Qui est appelée avec :

class Service(SchedulingItem):
   #AutoSlots create the __slots__ with properties and
   #running_properties names
   __metaclass__ = AutoSlots

[..]

Maintenant les __slots__ sont construits à la volée, et il n’y a plus de risque d’oublier des paramètres et mes classes Host/Service se re-concentrent un peu sur ce qu’elles doivent faire, et non sur une astuce pour contourner une consommation excessive de RAM par Python.

Les escalades de notifications enfin simples à mettre en place

Posted in Shinken by Nap on January 25, 2010

J’ai rajouté dernièrement le support des escalades de notifications. Pour rappel, elles permettent d’envoyer à d’autres contacts les notifications lorsqu’un problème persiste. Par exemple, vous pouvez définir pour le service CPU sur main-server un escalade qui va prévenir les chefs si au bout de 3 notifications le problème n’est pas résolu :

define serviceescalation{
host_name       main-server
service_description      Load
contacts                 chef, grandchecf, coupeurdetete
first_notification       3
last_notification        0
notification_interval    20
escalation_period        24×7
escalation_options       w,u,c,r
}

Cependant, cette forme de définition pose un problème : elle va s’appliquer sur des éléments, ici des services, au lieu d’être appelée par ces éléments.

Par clair? Disons qu’ici pour l’utiliser sur un service c’est sympa, mais en général on aimerait bien l’avoir pour un groupe de service, ou un groupe d’hôte, saufs certains service ou hôtes, etc. Bien sûr on a la possibilité de mettre * ou hostgroup_name, mais c’est vite limité. Bref, avoir la possibilité d’avoir une véritable gestion par des techniques d’héritages pourrait être utile (additif et implicite notamment).

De plus, quand on y pense, ici encore on a bien souvent un héritage host-> service non? Genre si la machine serveur-1 tombe, on aimerait bien avoir cette même règle sur les services de cette machine. Mais Nagios ne pospose ue serviceescalation et hostescalation, donc c’est pardu pour l”héritage, surtout quand c’est une application sur des éléments, et non un appel de ces éléments.

C’est pourquoi j’ai rajouté un nouvel object dans Shinken : escalation. Bah oui, ni service, ni host. Ca a un air de déjà vu pour la définition :

define escalation{
escalation_name        ToBoss
contacts                 chef, grandchecf, coupeurdetete
first_notification       3
last_notification        0
notification_interval    20
escalation_period        24×7
escalation_options       w,u,c,r
}

Et après on l’appel depuis un hôte :

define host{
[...]
escalations        ToBoss
[...]
}

Après si on ne défini rien sur les services de cet hôte, ce paramètre sera automatiquement hérité (TODO : rajouter une option pour hériter implicitement ou non certains champs). Et avec une telle définition, c’est ultra simple de le rajouter dans les templates qu’il faut, et hop, la gestion des escalade faciles. Ceci me permettra peut être de réellement les utiliser un jour, car dans leur état actuel, leur définition est un véritable cauchemars sur les grands environnements…

Gestion des exclusions de timeperiods

Posted in Shinken by Nap on January 6, 2010

Et bien après une bataille qui avait des air de guerre épique, j’ai mis en place les exclusions de timeperiods. Après une première version un peu … bourrine, une nouvelle arrive qui passe les tests et qui en plus est rapide. Cette partie du code n’est pas celle que je préfère, car il faut dire que les problèmes des dates et de calcul d’intervalle, c’est touffu, surtout lorsque l’intervalle ressemble à ‘monday 3 – thursday 4 00:00-11:00,12:00-24:00‘ (soit entre le troisième lundi du mois et le 4ième jeudi). Et puis le plus marrant dans ces définitions, c’est que c’est relatif par rapport au moment où vous calculer…

Mine de rien, c’est sûrement la partie la plus complexe de l’outil. Bon je ne vais pas me plaindre, le module time de python a bien aidé. Bref, vous pouvez faire une déclaration du genre :
define timeperiod{
timeperiod_name 24×7
alias 24_Hours_A_Day,_7_Days_A_Week
sunday 00:00-24:00
monday 00:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
friday 00:00-24:00
saturday 00:00-24:00
exclude workhours
}

# ‘workhours’ timeperiod definition
define timeperiod{
timeperiod_name workhours
alias Normal Work Hours
monday 09:00-17:00
tuesday 09:00-17:00
wednesday 09:00-17:00
thursday 09:00-17:00
friday 09:00-17:00
}

Donc ici 24×7 sera sans les workhours (bon bah c’est un exemple hein, à vous de trouver quelque chose de plus utile….). Donc un check en 24×7 voulant être lancé vers 10h le sera à 17h en fait. Ceci gère aussi si les timeperiods dans exclude ont elles même des exclude bien sûr.

Après MySQL, Oracle et couchdb : Sqlite

Posted in Shinken by Nap on January 4, 2010

Voici l’arrivée dans Shinken du support du schéma Merlin sous Sqlite (merci Python pour le support natif et simple). Sqlite permet d’avoir une base de données à peu de frais, directement dans un fichier, sans tout le bordel qu’il y a autour lorsque l’on souhaite une petite base simple en local.

Les applications tierces n’auront plus d’excuses pour encore utiliser les fichiers plats, là on fait du Select en un temps records, installation de la base comprise.

La configuration du plugin est simple :
define plugin{
plugin_name ToMerlindb_Sqlite
plugin_type merlindb_sqlite
database_path /data/mabase.sqlite
}

Généralisation des modulations de résultats

Posted in Shinken by Nap on December 31, 2009 2 Comments

Comme vu dans des posts précédents, le fait de pouvoir changer des retours à la volée avant de les analyser peut être pratique, comme changer un critical en warning, ou bien un ok en critical. Sur la mailing list, Thomas Guyot-Sionnest a proposé de généraliser cela. C’est pourquoi je pense implémenter un nouvel objet dans Shinken (et oui, encore un :) ) : resultmodulation.

Ceci va ressembler à :

define resultmodulation{
resultmodulation_name     critical_is_warning           ;required
exit_codes_match                2                ;optionnal, list of code to change
output_match // ;optionnal, regexp for activation of exit_code if output match
exit_code_modulation       1                ;code that will be put if the code match
output_modulation              s///        ;optionnal regexp to change output
longoutput_modulation      s///      ;optionnal regexp to change long_output
modulation_period               24×7    ;period when to apply the modulation
}

Puis après dans les hôtes et service, on appelle le modulation, qui pourra être hérité de manière implicite:

define host{
[...]
resultmodulations critical_is_warning
}

On peut remarquer le s de resultmodulations. En effet, on peut avoir besoin de plusieurs modulations. Elles vont seulement être appliquées les unes à la suite des autres.

Il ne reste plus qu’à implémenter alors, et enlever les paramètres spécifiques comme hotperiod (dommage j’aimais bien ce nom :) )

Couchdb dans Shinken

Posted in Shinken by Nap on December 17, 2009 8 Comments

J’ai lu il n’y a pas longtemps des articles sur Couchdb (http://couchdb.apache.org). J’ai voulu voir un peu ce que ça donne en vrai. L’intérêt de ce type de base est de na pas avoir de table, mais une liste de documents. J’ai donc essayé de faire un plugin Broker pour avoir un export en Couchdb des services (faut bien commencer par quelque chose).

Ca tombe bien, il y a un module python-couchdb (http://code.google.com/p/couchdb-python/) ultra simple à utiliser (bah c’est du Python hein). Après une belle frayeur sur les perfs (40ms par entrée, ça commence à faire beaucoup à mon goût) dû au protocole Nagle de TCP (pour beaucoup d’envois de faible taille, il faut mettre la socket en NO_DELAY), j’ai été un peu plus rassuré : 1000 entrées insérées en 2secondes. Ce n’est pas ultra rapide, mais ce n’est pas ultra lent non plus. Ce que ça donne?

Ca :

shinken-couchdbPour l’instant seul la création des documents est faite, et ce uniquement pour les services (mais le reste est rapide). Pour la mise à jour (genre après un check :) ) il va falloir que je me penche sur les ‘views’ car il va falloir que je retrouve le service avant de le mettre à jour. En effet, pour l’instant l’id du document est son id (unique pour chaque service lors de la lecture de la conf). Je mettrais bien un truc du genre “srv-1/Cpu” comme id, un truc simple. Mais je ne me rappelle plus si dans Nagios les / sont autorisés dans les noms d’éléments (sinon comment savoir quel est la partie host de “srv-1/CPU/1″ pour le service CPU/1 de srv-1).

Quelqu’un a une proposition pour l’id des services? Si on arrive à trouver un mix du nom d’hôte/nom de service, on n’a pas besoin de faire de views pour retrouver l’id dans co, ça sera autrement plus efficace :)

PS: pour preuve que python-couchdb est ultra simple à utiliser : le broker reçoit les données dans un dictionnaire python (dict). Et bien pour créer le “document” en base, même pas besoin de créer un INSERT, VALUES and co, juste : db.create(dict) :mrgreen:

Oui le Python, c’est vraiment pour les feignasses 8-)

Shinken sur ZDNet!

Posted in Shinken by Nap on December 16, 2009 3 Comments

http://www.zdnet.de/it_business_technik_nagios_alte_probleme_und_neue_perspektiven_story-11000009-41524548-1.htm

C’est Gerhard Laußer qui est interviewé.  C’est un expert Nagios de la société ConSol (www.consol.de) et qui m’a déjà fournis de nombreux patchs pour Shinken. Dans l’article et l’interview, Garhard parle de Nagios et de son activité récente. Vu que je ne parle pas un traitre mot d’allemand, je n’ai pu lire que la traduction google de l’article (http://translate.google.fr/translate?js=y&prev=_t&hl=fr&ie=UTF-8&layout=1&eotf=1&u=http%3A%2F%2Fwww.zdnet.de%2Fit_business_technik_nagios_alte_probleme_und_neue_perspektiven_story-11000009-41524548-1.htm&sl=auto&tl=fr) mais Gerhard m’a dit avoir été sympa avec Shinken dans l’interview :)

Merci à lui.

Python et le Data-Driven programming

Posted in Shinken by Nap on December 16, 2009 4 Comments

Suite au post d’un journal sur linux-fr concernant Shinken et l’avenir de Nagios (http://linuxfr.org/~naparuba/29141.html) certains m’ont demandé pourquoi j’ai choisi le Python (www.python.org) pour Shinken. J’ai répondu que 80% du choix était dû à mon goût perso, 20% pour les qualités du langages sur la résolution du problème. Les 20% sont en fait le module Pyro (http://pyro.sourceforge.net/)pour les objets distants (un peu comme Corba, mais autrement plus simple à utiliser et plus dynamique (pas de déclaration de squelette)).

Et les 80% restant?

On peu un peu se demander ce qu’il y a dans les 80% restant. Outre le fait que le langage ne pique pas les yeux (et évite les nœuds … au cerveau), et qu’il a d’intégré un module pour la gestion des pools de process (lancement des checks en parallèle),  il a de réelles qualités sur son dynamisme qui permettent d’utiliser une vaste panoplie de paradigme de programmation. Il ne les fait pas tous bien entendu (genre la programmation logique (et le prolog)), mais il permets déjà d’utiliser les principaux:

  • programmation itérative et récursive
  • programmation orientée objet
  • programmation orientée aspect (decorator)

Bon c’est bien, mais le rapport avec la choucroute il et où? Et bien suivant la situation, avec Python on peut choisir, c’est plutôt sympa. Lorsque vous gérez des graphes, le récursif s’impose de lui même (ou alors vous être vraiment tordu…), en règle général c’est de l’objet, et dans quelques cas particuliers l’aspect.

Une matrice de création nommée ADN

Concernant l’objet, la création des objets n’est pas classique pour la plupart des types dans Shinken. Nagios utilise des techniques d’héritages sur des objets (hosts/services) qui ont de multiples propriétés (et c’est rien de le dire). Alors m’amuser à faire des constructeurs de 5 lignes non extensibles facilement, non merci. Si c’est pour faire ça, autant rester à faire du C.

C’est là que vient le data-driven (enfin je crois que c’est comme ça que ca s’appelle) : vous décrivez votre objet dans un tableau quelconque, et au lieu de coder ce que vous devez faire pour chaque propriétés, vous faire une boucle sur votre tableau de description pour faire l’action, avec outre le nom de la propriété, les informations dans ce tableau sur quoi faire pour telle propriété. C’est tout (bah oui, c’est tout con, d’ailleurs je l’ai fait avant de savoir comment ça s’appelait…). L’intérêt? Aucun si vote objet a trois pauvres propriétés, mais énorme si elles commencent à devenir nombreuses (genre une bonne vingtaine).

Comme pour la plupart des techniques de programmations, l’intérêt est d’avoir une factorisation des informations. Ici vos propriétés (et les propriétés de ces propriétés…) sont définies dans un seul endroit. Si vous voulez changer, rajouter, supprimer quelque chose, pas besoin d’aller parcourir l’ensemble du code. Celui-ci ne connait pas ce que vous avez mis comme données dans vos tableaux. Il sait les traiter, mais ne connait pas à l’avance ce qu’il y a dedans. Le tableau est une sorte d’ADN de l’objet : c’est sa matrice de fabrication.

Où qu’on le met cet ADN?

Ce qui est embêtant est d’accéder à ce tableau lors de vos traitement. Bien sûr il y a la méthode consistant à le mettre en variable global, mais les variables globales c’est un peu comme le goto : le mal absolu. Mettre le tableau dans chaque objet? Bof, c’est crade, un objet n’a pas besoin d’avoir son ADN d’accroché pour vivre une fois crée (vous utilisez votre ADN vous? Non, vous utilisez les protéines qu’il a permis de fabriquer). Python nous aide ici. Si vous faite objet.__class__ vous obtenez la classe de l’objet. Et oui, une classe est un objet. Et un objet en python peut se voir accrocher des propriétés… genre notre tableau.

Si on rajoute ceci à un héritage de nos objets à une classe “Item” qui va faire le travail de construction, on obtient une fabrique de n’importe quel objet le temps que l’on définisse son ADN dans la classe de l’objet. Pratique non? C’est diablement efficace pour factoriser le code à sa plus simple expression.

Et au final on y gagne beaucoup?

Vous voulez un exemple? Le code de Nagios pour juste la fabrication des objets avec les techniques d’héritages and co prends à lui seul plus de 11K lignes. Shinken dans son entier (architecture distribuée, configuration, envoi dans les bases de données, ordonnancement, etc) en prends un peu plus de 8K. Owned comme dirait l’autre.

Il fait chaud chaud cet hiver

Posted in Shinken by Nap on December 15, 2009 2 Comments

Ca y est, les hot_period sont implémentées (cf http://www.gabes.fr/jean/2009/12/14/hot-periods). Au passage j’ai viré la dépendance à python-graph-core, plus d’erreurs avec digraph suivant la version de python-graph que vous utilisez. En plus les histoire de graph c’est toujours marrant…

« Previous PageNext Page »