[trigger] Nettoyage, et readme mis à jour:
This commit is contained in:
Pierre-Elliott Bécue
parent
56d73814db
commit
5a4792d820
6 changed files with 112 additions and 37 deletions
|
|
@ -1,5 +0,0 @@
|
||||||
#!/bin/bash /usr/scripts/python.sh
|
|
||||||
# -*- coding: utf-8 -*-
|
|
||||||
|
|
||||||
from gestion.trigger.event import event
|
|
||||||
from gestion.trigger.host import trigger
|
|
||||||
|
|
@ -1,5 +0,0 @@
|
||||||
#!/bin/bash /usr/scripts/python.sh
|
|
||||||
# -*- coding: utf-8 -*-
|
|
||||||
|
|
||||||
from gestion.trigger.dhcp
|
|
||||||
from gestion.trigger.host import trigger
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
dhcp.py
|
|
||||||
|
|
@ -1,26 +0,0 @@
|
||||||
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.
|
|
||||||
112
gestion/trigger/readme.fr
Normal file
112
gestion/trigger/readme.fr
Normal file
|
|
@ -0,0 +1,112 @@
|
||||||
|
Auteur : PEB <becue@crans.org>
|
||||||
|
Date : 14/07/2014
|
||||||
|
Licence : GPLv3
|
||||||
|
|
||||||
|
Documentation succincte de trigger
|
||||||
|
==================================
|
||||||
|
|
||||||
|
Tous les fichiers sont renseignés depuis /usr/scripts.
|
||||||
|
|
||||||
|
Trigger est une sorte de librairie de remplacement de generate et des services
|
||||||
|
dans la base LDAP, qui fonctionnent avec bien trop de délai.
|
||||||
|
|
||||||
|
Trigger est le fruit d'une longue et intelligente (quelle modestie) réflexion,
|
||||||
|
et donc nous allons ici décrire son fonctionnement.
|
||||||
|
|
||||||
|
* gestion/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 gestion/config/trigger.py, il y a la liste
|
||||||
|
des services que chaque hôte gère. Ainsi, gestion/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, le seul service présent est
|
||||||
|
dhcp, et donc trigger va aller chercher gestion/trigger/service/dhcp.py, et
|
||||||
|
travailler avec.
|
||||||
|
* gestion/trigger/trigger.py importe une méthode trigger depuis
|
||||||
|
gestion/trigger/host.py. Cette méthode permet d'aller puiser dans une factory
|
||||||
|
portant le nom TriggerFactory les références vers les services utiles. Cela
|
||||||
|
permet ensuite de les régénérer à la volée.
|
||||||
|
|
||||||
|
* Le dossier gestion/trigger/services contient la liste des services existants
|
||||||
|
pour trigger. Le fonctionnement des services sera détaillé ci-après.
|
||||||
|
|
||||||
|
Fonctionnement des services
|
||||||
|
===========================
|
||||||
|
|
||||||
|
"Un service est une classe qui ne sera jamais instanciée"
|
||||||
|
|
||||||
|
Un service est la donnée dans un fichier d'une classe portant le nom du fichier
|
||||||
|
(et donc du service). La casse dans le nom de la classe n'importe pas. Cette
|
||||||
|
classe hérite de BasicService, une classe définie dans
|
||||||
|
gestion/trigger/services/service.py. Cette classe s'appuie sur la métaclasse
|
||||||
|
MetaService pour se construire, ce qui permet d'établir un certain nombre de
|
||||||
|
liens entre les méthodes d'une classe représentant un service et des attributs
|
||||||
|
de lc_ldap que l'on souhaite monitorer. La métaclasse et l'ensemble des liens
|
||||||
|
susmentionnés n'ont d'intérêt que pour la partie "transcription des modifs de la
|
||||||
|
base LDAP dans un langage compréhensible par les services".
|
||||||
|
|
||||||
|
Enfin, tout service contient une méthode regen prévue pour régénérer ledit
|
||||||
|
service.
|
||||||
|
|
||||||
|
Les services peuvent ensuite contenir autant de méthodes que souhaitées, dans la
|
||||||
|
mesure où se sont des méthodes de classe ou statiques.
|
||||||
|
|
||||||
|
La variable faisant le lien entre les attributs ldap à monitorer et les
|
||||||
|
fonctions à appeler pour transcrire les changements s'appelle changes_trigger.
|
||||||
|
C'est un dictionnaire dont les clefs sont le nom des attributs ldap à
|
||||||
|
surveiller, et les valeurs des tuples contenant les noms des fonctions à
|
||||||
|
appeler en cas de changement.
|
||||||
|
|
||||||
|
Ces fonctions devront toujours avoir le prototype suivant :
|
||||||
|
@classmethod
|
||||||
|
def toto(cls, body, diff):
|
||||||
|
où body et diff sont gérés et fournis tels quels par le service event. body est
|
||||||
|
un 3-tuple contenant le dn de l'objet ldap modifié, la liste des clefs avant
|
||||||
|
modification, et celle après. diff est un dictionnaire de différences calculé
|
||||||
|
entre body[1] et body[2].
|
||||||
|
|
||||||
|
Ajouter un nouveau service
|
||||||
|
==========================
|
||||||
|
|
||||||
|
Pour ajouter un service, il faut créer un fichier adapté dans trigger/services/,
|
||||||
|
puis, définir une classe héritant de BasicService, et respecter quelques règles
|
||||||
|
primordiales.
|
||||||
|
|
||||||
|
Premièrement, ce service sera importé sur chaque machine où il est configuré
|
||||||
|
pour fonctionner, et sur civet dans event.py. Pensez donc une fois le tout
|
||||||
|
configuré à relancer trigger sur civet, et à vérifier que ça marche. La variable
|
||||||
|
de configuration debug dans gestion/config/trigger.py est là pour aider. Parmi
|
||||||
|
les choses importantes, l'idéal est d'avoir des dépendances les plus paresseuses
|
||||||
|
possibles d'un point de vue évaluation. Ainsi, civet qui ne fait qu'importer le
|
||||||
|
fichier et utiliser les fonctions d'analyse listées dans changes_trigger peut
|
||||||
|
éviter de jouer avec ce qui ne le concerne pas.
|
||||||
|
|
||||||
|
Ensuite, il faut absolument une méthode regen, et définir changes_trigger. (un
|
||||||
|
dict vide convient)
|
||||||
|
|
||||||
|
Enfin, si vous avez des questions, posez-les avant, pas après.
|
||||||
|
|
||||||
|
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 le service event, dans gestion/trigger/services/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 idoine.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Cela permet aussi d'avoir des définitions de services précises d'un point de vue
|
||||||
|
spécification, et une portabilité plus que correcte de trigger d'un binding vers
|
||||||
|
un autre. (les seules données ldap qui l'intéressent sont les noms des
|
||||||
|
attributs, définis dans le schéma de la base ldap, il faut donc que le binding
|
||||||
|
fournisse ses données avec les mêmes noms)
|
||||||
Loading…
Add table
Add a link
Reference in a new issue