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.
> 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.
> 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 ?
> 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.
> 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à.
> Je pourrai filer un coup de main. Reste à avoir l'aval des
> développeurs du coeur de GLPI.
Moi de même.
Cordialement,
Gonéri Le Bouder
signature.asc
Description: Digital signature
_______________________________________________ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
