On 09/12/2011 10:14, Gonéri Le Bouder wrote:
On Wed, Dec 07, 2011 at 08:30:39PM +0100, Damien Touraine wrote:
Bonjour,
Bonjour Damien,
J'ai un petit peu bossé sur l'évolution de la partie réseau pour la
0.84. Il y a eu quelques petits changements par rapport aux
spécifications sur le wiki (d'ailleurs, je vais devoir les mettre à
jours) :
Le Netpoint est, effectivement, une prise "murale". Mais cela peut
contenir, également, le numéro de port sur le bandeau de brassage.
Le NetworkPort doit être vu comme un port physique ou logique
(trunk) au sein d'un équipement
J'ai du mal a comprendre la différence entre le Netpoint et NetworkPort
Je pense qu'une prise murale ou un bandeau de brassage sont des
périphériques et a ce titre, leurs prises doivent pouvoir être
associées à cette équipement.
Or un netpoint n'a pas de items_id, itemtype, contrairement à un
networkport.
J'ai donc l'impression que NetworkPort peut être utilisé partout.
De mon point de vue (cela n'engage que moi), le NetworkPort est un port
physique de l'équippement : nous pourrions l'assimiler à la couche 0 du
modèle ISO (couche physique). C'est un équippement actif qui représente
une connexion vers le monde exterieur de l'équippement.
Inversement, un Netpoint est un élément passif du réseau par lequel
transite des informations réseau.
Ce que vous proposez est intéressant.
Mais, plutôt que de parler de media, je parlerais de lien
(NetworkLink).
Ok.
Shéma : équipement terminal (ordinateur, switch, téléphone, ...)<-
NetworkPort (NetworkPortEthernet)<- NetworkLink -> NetworkPort
(NetworkPortEthernet) -> équipement terminal
Les Netpoints auraient divers éléments, chacun avec son numéro
d'ordre sur le NetworkLink.
Je suis d'accord sauf que je ne vois pas où sont les netpoints dans
cette représentation.
Les Netpoint seraient attachés, avec un numéro d'ordre au NetworkLink,
celui-ci représentant un lien "physique" (y compris les connexions
"wireless") entre deux NetworkPort.
Pour commencer, le NetworkLink serait un renommage du
NetworkPort_NetworkPort. Ensuite, il faudrait rediriger les Netpoint
vers cette nouvelle classe.
Ok, donc on a la même conclustion sur les netpoints ?
Tout à fait.
La 0.84 propose le WifiNetwork qui contient l'ESSID et le mode de
gestion (ad-hoc, avec access point). Les NetworkPortWifi s'y
"connectent". On peut l'étendre en ajoutant la version Wifi (a, a/b,
a/b/g, ...), le type de clef de sécurité, le canal, ... Si c'est
nécessaire, nous pourrions ajouter les contrats dans le
NetworkPortWifi ou un plugin qui vient s'y ajouter.
Je viens de voir la table glpi_wifinetworks. Cette représentation me
gène car elle ne permet pas de faire la différence entre un réseau
mesh et plusieurs AP avec le même ESSID.
Personnellement, je pense que des flags :
NetworkPortWifi.is_ap
NetworkPortWifi.is_mesh
sont suffisants pour avoir un niveau d'information supérieur.
Comme je le disais, on peut étendre le WifiNetwork pour y ajouter des
attributs supplémentaires tel que is_ap ou is_mesh (mais les deux ne
sont-ils pas exclusifs ?). Mais nous pourrions avoir à distinguer des
réseaux wifi "identiques" (ie : même mode, même ESSID, même canal, ...)
mais qui différent pas des éléments géographiques tel que le bâtiment
les contenant.
Concernant les onduleurs, l'intégration dans FusionInventory, puis
dans GLPI serait une bonne chose (mais ne pas oublier les
alimentations redondantes dont tient compte NUT).
Nous n'en avons pas encore discuté, je pense qu'on va le traiter dans un
second temps.
Une solution similaire à celle du NetworkLink (PowerLink ?) serait réalisable
...
Pourquoi ne pas juste parler de Link puis de NetworkLinux et de PowerLink.
Malheureusement, une table glpi_links existe déjà.
Intrinsèquement, un NetworkLink est beaucoup plus riche qu'un PowerLink
(Fibre, RJ-45, Infiniband, Ethernet, ...). De plus, nous avons la notion
de NetworkPort qui joue le rôle d'interface entre le NetworkLink et
l'équippement. Sans aller dans les détails, je pense que nous ne pouvons
pas "confondre" les deux.
Je pourrai filer un coup de main. Reste à avoir l'aval des
développeurs du coeur de GLPI.
Moi de même.
Comme je le dis plus haut, ces réflexions n'engagent que moi. Donc,
avant tout développement, je préfère attendre l'aval des développeurs du
coeur de GLPI.
De plus la 0.84 vient à peine de passer en "trunk". Je pense qu'il faut
commencer par valider la 0.83 et confirmer les dernières évolutions sur
la 0.84 avant d'aller plus loin.
Damien
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
