[trigger] Réinventer la roue alors qu'on l'a déjà créée dans le dossier.

* Ça sert à rien de créer un transcriptor spécifique alors qu'on a déjà
 tout ce qu'il faut avec trigger.py pour gérer le bouzin. Il suffit
 d'une méthode event décorée avec record dans event.py...

gestion/trigger/readme

@@ -1,4 +1,29 @@
 Documentation succincte de trigger
 ==================================
 
+Tous les fichiers sont renseignés depuis /usr/scripts/gestion.
 
+Trigger est une sorte de librairie de remplacement de generate et des services dans la base LDAP, qui marchent mal et qui sont une suite de patches.
+
+Trigger est le fruit d'une longue et intelligente (quelle modestie) réflexion, et donc nous allons ici décrire son fonctionnement.
+
+ * trigger/trigger.py est un fichier python qui importe un consumer de la librairie cmb. Il marche de manière asynchrone, c'est-à-dire qu'il attend et traîte les messages un par un. Dans config/trigger.py, il y a la liste des services que chaque hôte gère. Ainsi, trigger/trigger.py sait, en fonction de l'hôte sur lequel il se trouve, comment il doit se comporter, et ce qu'il doit importer.
+
+ * Par exemple, sur l'hôte dhcp, trigger/trigger.py importe trigger/hosts/dhcp.py, qui décrit la gestion des services sur dhcp.
+ * Dans le fichier d'un hôte, on importe toujours trigger/host.py, qui fournit la méthode trigger(about)(body). About doit renseigner une méthode accessible par trigger/hosts/dhcp.py, et décorée avec "record" (chargée depuis trigger/host.py). record met dans une factory la méthode, et la rend accessible via la méthode trigger(about), qui retourne ladite méthode. body est donc passé en argument.
+
+Ajouter un nouveau service
+==========================
+
+Si c'est un service partagé par plusieurs hôtes, il vaut mieux créer tout ce qu'il faut dans trigger/nomduservice.py, écrire tout ce dont on a besoin, décorer la méthode (dont le nom est celui du service, donc si ça parle de dhcp, appeler la fonction dhcp, et mettre dhcp dans config/trigger.py) par un @record (penser à importer record depuis trigger/host.py). Une fois le service au point, importer les méthodes "recordées", et la méthode trigger depuis trigger/host.py.
+
+Si c'est un service simple utilisé que par un seul hôte, vous pouvez le mettre directement dans la description de l'hôte dans hosts/nomdelhôte.py. La nomenclature des noms de fonctions et de @record ne change pas.
+
+Pour chaque service, une "file d'attente" rabbitmq est créée ayant le nom trigger-nomdel'hôte-nomduservice, et une clef de routage du type trigger.nomduservice est mise en place pour que les messages envoyés vers trigger.nomduservice soient dispatchés sur l'ensemble des queues trigger-*-nomduservice.
+
+Un service spécial
+==================
+
+civet est un hôte spécial, qui gère un service spécial : le transcripteur. Le transcripteur est une fonction event, dans trigger/event.py, qui reçoit des messages sur la queue trigger-civet-event. C'est lui qui, fonction des messages reçus, les répartis tous vers les autres queues avec clef de routage.
+
+L'intérêt est d'assurer une indépendance maximale entre binding ldap et la librairie trigger : le binding doit juste envoyer avec clef de routage trigger.event les modifs qu'il fait, et c'est la librairie elle-même qui gère les envois en son sein.