Re: [sympa-fr] Ajout de robot à la volée

[David Verdin <adresse@cachée>]

Bonjour,

Vous nous présentez-là quelque chose de nouveau !

Le 09/07/2010 08:41, Julien Arnoux a écrit :

Bonjour à tous,

Existe t'il un moyen d'ajouter des robots via SOAP à la 
volée et sans redémarrage du serveur Sympa ?
  

Pas pour le moment.

Voilà comment j'ai procédé:
J'ai ajouté une méthode soap "addDomain" qui s'occupe de créer la conf
du robot souhaité ainsi que les alias ldap correspondant.

Intéressant. S'il était possible d'aller au bout de ce développement, je pense que cela serait utile de l'ajouter au code principal de Sympa. Mais comme nous allons le voir, ça ne va pas être facile.

 Jusqu'ici tout va bien.
Le problème se pose si l'on essai de créer une liste utilisant le robot
fraichement ajouté. Apparemment le nouveau robot n'est pas chargé en configuration
par Sympa et donc la création de la liste se passe très mal. Si par contre
je reboot le serveur Sympa entre l'ajout du robot et la création de la liste tout va bien!
  

En effet. Les processus Sympa ne chargent leur configuration que lors du démarrage. Ils la charngent en mémoire et ne la modifient plus.
Certes, ils serait très simple d'implémenter une fonction dont le rôle serait justement de recharger la configuration, mais le poblème n'est pas là. Le problème est de savoir quand la recharge. En effet, c'est une opération coûteuse, donc on ne peut pas le faire à chaque tour de boucle. Il faut donc envoyer un signal aux processus pour qu'ils rechargent et c'est là que les ennuis commencent.

En effet, l'exécution de Sympa requiert celle de sept types de programmes résidents :

• sympa.pl
• archived.pl
• bounced.pl
• task_manager.pl
• bulk.pl (1 à n instances) pour les versions 6 de Sympa
• wwsympa.fcgi (1 à n instances lancées par le serveur web)
• sympa_soap_server.fcgi (également lancé par le serveur web).

Tous ces processus sont exécutés indépendamment les uns des autres. Il n'y a pas de communication inter process pour la bonne raison que nous n'en avons jamais ressenti le besoin : chaque processus exécute une taĉhe spécialisée. Il lit et écrit dans certains spools et effectue des opérations métier, c'est tout.

Or si on change la config, on veut que tous les process prennent en compte cette modification immédiatement.

Dans votre cas, c'est l'interface SOAP qui va modifier la config. On peut donc forcer sympa_soap_server.fcgi à recharger la config dès qu'il a créé le robot. C'est une petite fonction à écrire et hop. Le problème c'est que tous les autres process tournent toujours sur l'ancienne config. Et comme le serveur SOAP ce peut pas communiquer avec eux, le seul moyen pour que le nouveau robot soit pris en compte est bien de relancer les processus Sympa et le serveur web (un reload apache ne suffit pas, il faut relancer les fcgi ce que seul un redémarrage permet, à ma connaissance). La boucle est bouclée.

Alors comment faire pour que tous les processus prennent en compte un changement de config ?

Une solution que nous évoquons pour le moment serait qu'à chaque tour de boucle (ou tous les n tours) tout processus de Sympa effectue une vérification peu coûteuse pour savoir s'il doit recharger la config. La nature de cette vérification est à discuter mais, en supposant que tous les process de Sympa tournent sur une seule machine, une simple vérification de la date de modification du fichier devrait faire l'affaire.

À terme, cela ne suffira plus puisque Sympa évolue en ce moment vers une architecture multi-serveur, ce qui permettra d'assurer de la haute disponibilité et de la répartition de charge. Il est d'ores et déjà possible de faire tourner bulk.pl sur plusieurs serveurs car les seules données dont il a besoin se trouvent en base de données, il a donc juste besoin de sympa.conf.
On va à terme se retrouver avec des problèmes de synchro d'un serveur à l'autre.
Comme tous les spools seront bientôt en base de données, nous pouvons envisager de créer un spool administratif, surveillé par tous les processus, dans lequel chacun pourra écrire, et dans lequel seront déposées des directives telles que "recharger la configuration" et d'autres si nécessaire.

Un première piste de travail serait sans doute :

1- regrouper toutes les initialisations liées à la configuration au sein d'un même fonction pour chaque exécutable. Appelons-là "init_conf()"; cette fonction correspond à tout ce qui, au sein du process, se déroule entre le moment où on appelle Conf::load() et le début de la boucle infinie. Notez que tout ce qui s'y trouve n'a pas nécessairement vaocation à être factorié dans "init_conf()". Dans sympa.pl, par exemple, toute une partie du code consiste à traiter les options de démarrages qui, par définition, ne changent pas en cours d'exécution. Je ne joins pas de code, parce que le contenu de cette fonction varie d'un exécutable à l'autre, mais cette factorisation doit être effectuée pour chaque exécutable.

2- Faire vérifier à sympa son fichier de config :

Avant le lancement de la boucle infinie :

my $config_file = $main::options{'config'} || Sympa::Constants::CONFIG; # Pour wwsympa.fcgi et sympa_soap_server.fcgi, il y a deux fichiers à charger séparément.
my $config_update = stat($config_file)->mtime;
my $config_check_loop_count = 0;
init_conf();

Dans la boucle :

if ($config_check_loop_count > 1) {
    if(stat($config_file)->mtime > $config_update) {
        &Log::do_log('info','Reloading config');
        init_conf();
        $config_update = stat($config_file)->mtime;
    }
    $config_check_loop_count=0;
}
$config_check_loop_count++;
Voilà. c'est l'idée en gros, mais il fau faire bien attention au contenu de "init_conf()".

Jusqu'à maintenant je procède ainsi mais le nombre de listes étant de plus en plus grand
le reboot prend de plus en plus de temps.
  

Combien de listes, par curiosité ?
Est-ce que vous utilisez les config.bin ? Ça accélère largement le parcours des config de listes. voir https://www.sympa.org/manual/conf-parameters/part3#cache_list_config

Par ailleurs, il y a une page dans la FAQ de Sympa sur les performances : https://www.sympa.org/faq/performances

Peut-être existe t'il un moyen d'indiquer à Sympa de prendre en compte se nouveau 
robot à la volé ?

Si aucun moyen n'est trouvé je serai obligé de créer au préalable tous les robots
pour tous les clients (et ainsi éviter ce reboot). 
Sympa pourra t'il gérer environs 90 000 robots différents ?
  

Une fois les configs lues, oui (encore qu'on peut prévoir une sévère augmentation de la consommation de mémoire vive) mais le simple parcours du répertoire expl ou etc va coûter cher au démarrage. On y fait tout de même des readdit régulièrement. Cela me semble représenter une forte consommation de ressources par rapport au gain.

J'espère que tout cela vous aura été utile.

Cordialement,

David Verdin

P.S.: J'ignorais qu'Infomaniak proposait Sympa comme service à ses clients. Peut-on vous ajouter à la liste des hébergeurs sur https://www.sympa.org/users/custom ?

Merci d'avance.


  

--
David Verdin
Comité réseau des universités

Due to the limitations of human brain, I fail to remember all the mails.
So if you want your bug reports or feature requests for Sympa to be processed, please post them to the Sympa tracker