CR Réunion / Orientations

[Damien Lucas]

A l'odj:
  1- Les GPAs
  2- Le VLANserver actuel
  3- La release
  4- Le nouveau CHANNELserver (vlcs)
  5- Quelques "détails"

1- Les GPAs
-----------
  Tonney:  a déjà codé une fonction dans snmp
  Lool:    a déjà codé une focntion dans interface/telnet
  Marcari: a déjà codé l'intégration du changement de chaine au vlc
  Babal:   codera peut-être plus tard sur le vlcs 


2- Le VLANserver actuel
-----------------------
  Seul bug connu à l'heure actuel, certaines MACs ne sont pas trouvées
  alors que la machine associée est conue du switch.

3- La Release
-------------
  Objectif: Ce week-end
  D'ici là:
   . Eviter si possible le message de warning dans la libsnmp (nitrox)
   . Proprifier le code
           (. en-tête avant les fonctions,
            . wrapper les lignes
            . Rajouter un tag CVS dans le fichier: $Id)       (nitrox)
   . Ecrire une FAQ                                           (bbp)
   . Anonce WEB/ML                                            (gunther)


4- Le nouveau CHANNELserver
---------------------------

4-1 Description


  Le noyau central SERVER:
    son rôle est de faire communiquer les modules.
    il transmet les requêtes à l'ensemble des modules qui en ont besoin

  Le module INTF
    finalement pas séparé avec un INTF2
    il comportera entre autre les modules VIDEOLANP, TELNETD, ...
    c'est la partie visible de l'extérieur

  Le module DB
    il contient la base de données.

  Le module NETWORK
    Divisé en L2 et L3 puis (ETH,TR) et (ATM,IP) à nouveau redivisé
    
  Le module INTFS
    Désigne la communication avec les serveurs video

  (Le module STAT)
    Il pourrait stater toutes les demandes de changement de chaine par exemple


4-2 Fonctionnement
   
  
   Chacun des modules cités ci-dessus doit fournir une liste d'action.
   Par exemple pour INTF:
     Changer de chaine
     Obtenir des infos
     Demander la reload de la config
     ...


4-3 Exemple


   ci dessous: la description de la demande de changement de chaine:

   VIDEOLANP_ch_channel()
   {
     ...
     INTF_ch_channel();
     ...
   }


   INTF_ch_channel()
   {
     ...
     SERVER_ch_channel();
     ...
   }


   SERVER_ch_channel()
   {
     STATS_ch_channel();
     NETWORK_ch_channel();
   }

   NETWORK_ch_channel();
   {
     ...
     SERVER_get_info();    /* sur la machine qui demande */
     ...
     if(method==L2)
       L2_ch_channel();
     else if(method==L3)
       L3_ch_channel();
     endif
   }

  SERVER_get_info()
  {
    DB_get_info();
  }


4-4 Répartition du travail

    Il s'agit de réfléchir à la liste des "fonctions effectives" que l'ont
    souhaite  voir dans chaque module et la liste des objets importants
    du module (vu de l'extérieur ie pas les objets internes)

    intfs:   babal              mardi après la rdb
    config:  nitrox             samedi 16h30
    DB:      bbp                samedi 14h
    intf;    gunther lool marc  mardi 14h
    network: nitrox tooney      dimanche 16h



5- Quelques détails
-------------------


   Il restait quelques questions:


5-1 DNS/IP
    

   Il a été décidé qu'il serait bon de pouvoir spécifier dans le fichier
   de  config si  les  DNS devaient  être  résolu à  chaque  fois ou  au
   lancement ce  qui demande de  stocker un  cache DNS d'une  manière ou
   d'une autre  Il a été évoque  l'idée de mettre pour  chaque entité un
   champ DNS et un champ IP


5-2 libsnmp

   La quesion était  de savoir si compte-tenu de  toutes merdes qu'elles
   contient on écrirait notre propre  lib. Je (nitrox) pense qu'avant de
   voir  à  écrire  notre  propre  lib, il  faudrait  connaître  à  fond
   celle-ci afin de l'utiliser correctement. Dans un premier temps, nous
   reposerons donc sur la libsnmp (net-snmp 4.2)


5-3 Le Vlanbridge 

   Deux  questions: 1-  Faut-il  le releaser?  2-  Faut-il relancer  son
   développement? A  la première question il  a été répondu non  dans la
   mesure où personne ne connait suffisamment le code pour le maintenir.
   A la desième  question, il a été  répondu non dans la  mesure où rien
   n'urge dans ce qu'il reste à y coder.




Faites péter les remarques !


-- 
nitrox