26 lines
2.7 KiB
Text
26 lines
2.7 KiB
Text
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
|
|
==========================
|
|
Créer tout ce qu'il faut dans trigger/services/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, si vous avez mis à jour config/trigger.py, c'est bon.
|
|
|
|
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.
|