Re: [Glpi-dev] patch d'évolution du NetworkPort
Bonjour, On 05/12/2011 15:50, David DURIEUX wrote: j'ai commencé à regardé ce que tu as mis sur le SVN pour la 0.84 J'ai quelques remarques : * On devrait séparer les noms reseau des IP; en effet, un port peut avoir plusieurs IP et pas de nom reseau. par exemple pour un port d'ordinateur ou pour l'IP/les IP d'un switch En effet, il n'y a pas de bijection entre les noms réseaux et les adresses IP. Un nom réseau peut être affecté à plusieurs adresses IP (cas du load balancing), et une adresse IP peut avoir plusieurs noms réseau différents (alias dans les DNS). Mais, en règle générale et traditionnellement, on associe un nom principal à une adresse IP donnée. D'une part, c'est beaucoup plus pratique que de saisir l'adresse (surtout en IPv6 ...). D'autre part, certaines applications (ssh, ...) utilisent la résolution inverse des adresses IP pour s'assurer de la conformité de la demande de connexion. C'est, également, utilisé pour les "logs" de connexion. Pour le moment, il FAUT saisir un nom réseau non vide. Sinon, le NetworkName n'est pas ajouté/modifié. Ce comportement peut, effectivement, poser problème. Dès que la bascule 0.84->trunk aura eu lieu, je le supprimerai. * Il faudrait un champs unique pour chaque IP et pas une textarea, ceci permettra de fair eune recherche plus rapide dans la DB et ça sera plus clair dans l'interface (une ligne par IP par exemple pour l'affichage) Dans le cadre de l'IPv6, un même nom doit être résolu en IPv4, en IPv6 link-local et en IPv6 link-global. C'est la même connexion (le même nom), mais vue selon des versions d'IP différentes et de lieux différents. Cela va avoir tendance à se généraliser avec l'émergeance d'IPv6. C'est pour cela que l'adresse IP, dans le NetworkName, est un textarea permettant la saisie de plusieurs adresses. Mais, lors de la validation, le NetworkName sépare et valide chacune des adresses séparément. Les nouvelles adresses sont ajoutées dans la base de données glpi_ipaddresses (et les anciennes supprimées). Lors des requêtes pour trouver une adresse, c'est cette dernière qui est interrogée. Le champs `ip_addresses` de glpi_networknames n'est là qu'entant que cache des adresses. Il sert, notamment, lors de l'affichage des adresses du nom réseau par Search::show. Cordialement Damien ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] patch d'évolution du NetworkPort
j'ai commencé à regardé ce que tu as mis sur le SVN pour la 0.84 J'ai quelques remarques : * On devrait séparer les noms reseau des IP; en effet, un port peut avoir plusieurs IP et pas de nom reseau. par exemple pour un port d'ordinateur ou pour l'IP/les IP d'un switch * Il faudrait un champs unique pour chaque IP et pas une textarea, ceci permettra de fair eune recherche plus rapide dans la DB et ça sera plus clair dans l'interface (une ligne par IP par exemple pour l'affichage) David Durieux ++ Le Thu, 15 Sep 2011 08:36:49 +0200 Damien Touraine a écrit: >Bonjour, > >Ce boulot est largement facilité par la programmation orientée objet >et les bases de GLPI qui me semblent très saines. Mais il ne faut pas >se fier à la taille des patchs : il y a du ménage à faire dedans >(ie. : mélange de deux conceptions des NetworkPort différentes). > >Le report à la version 0.84 me semble d'autant plus justifié que le >chantier de la 0.83 est déjà bien avancé. De plus, l'intégration de >cela sera l'occasion de réfléchir à son articulation avec, notamment, >le système d'import OCS. Deux choix me semblent possibles : >1°) solution actuelle : une adresse IP <=> un port réseau (et une >adresses IP <=> un équippement réseau) ; >2°) solution plus proche de la réalité : une carte réseau <= > un port >réseau sur lequel peut être attaché plusieurs adresses IP. > >Le parrainage est nécessaire. En effet, je ne connais pas assez GLPI >(notamment les us et coutumes) pour être laissé libre dans la >publication directe dans le SVN. > >Cordialement > Damien >On 09/14/11 23:46, jmd wrote: >> Bonsoir, >> >> Une remarque préalable : un boulot impressionnant ! >> >> Ensuite, une remarque globale par rapport à l'ampleur du chantier, >> nous sommes tentés de vous proposer le plan suivant : >> >> - Report de l'implémentation sur la version 0.84 de façon à >> travailler de façon plus sereine. La cible initiale (0.83) nous >> semble difficilement tenable. >> >> - Découpage du chantier en différents tickets (étapes) >> >> - Ouverture d'un accés sur le SVN et attribution d'un parrain qui >> vérifiera les comits. Le travail par le biais de patchs nous >> semblent difficile et peu efficace vu l'impact des modifications >> envisagées. >> >> >> Bien cordialement, >> >> >> -- >> Jean-Mathieu Doléans >> GLPI-PROJECT.ORG >> >> ___ >> Glpi-dev mailing list >> Glpi-dev@gna.org >> https://mail.gna.org/listinfo/glpi-dev >> > > ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] patch d'évolution du NetworkPort
Bonjour, Ce boulot est largement facilité par la programmation orientée objet et les bases de GLPI qui me semblent très saines. Mais il ne faut pas se fier à la taille des patchs : il y a du ménage à faire dedans (ie. : mélange de deux conceptions des NetworkPort différentes). Le report à la version 0.84 me semble d'autant plus justifié que le chantier de la 0.83 est déjà bien avancé. De plus, l'intégration de cela sera l'occasion de réfléchir à son articulation avec, notamment, le système d'import OCS. Deux choix me semblent possibles : 1°) solution actuelle : une adresse IP <=> un port réseau (et une adresses IP <=> un équippement réseau) ; 2°) solution plus proche de la réalité : une carte réseau <= > un port réseau sur lequel peut être attaché plusieurs adresses IP. Le parrainage est nécessaire. En effet, je ne connais pas assez GLPI (notamment les us et coutumes) pour être laissé libre dans la publication directe dans le SVN. Cordialement Damien On 09/14/11 23:46, jmd wrote: Bonsoir, Une remarque préalable : un boulot impressionnant ! Ensuite, une remarque globale par rapport à l'ampleur du chantier, nous sommes tentés de vous proposer le plan suivant : - Report de l'implémentation sur la version 0.84 de façon à travailler de façon plus sereine. La cible initiale (0.83) nous semble difficilement tenable. - Découpage du chantier en différents tickets (étapes) - Ouverture d'un accés sur le SVN et attribution d'un parrain qui vérifiera les comits. Le travail par le biais de patchs nous semblent difficile et peu efficace vu l'impact des modifications envisagées. Bien cordialement, -- Jean-Mathieu Doléans GLPI-PROJECT.ORG ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev -- Damien TOURAINE - Ingénieur de Recherche CNRS, LIMSI-CNRS Groupe de RV&A "VENISE", (http://www.limsi.fr/venise/) Bat. 508, Universite Paris-Sud 91403 Orsay cedex - +33 1 69 85 81 64 ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] patch d'évolution du NetworkPort
Bonsoir, Une remarque préalable : un boulot impressionnant ! Ensuite, une remarque globale par rapport à l'ampleur du chantier, nous sommes tentés de vous proposer le plan suivant : - Report de l'implémentation sur la version 0.84 de façon à travailler de façon plus sereine. La cible initiale (0.83) nous semble difficilement tenable. - Découpage du chantier en différents tickets (étapes) - Ouverture d'un accés sur le SVN et attribution d'un parrain qui vérifiera les comits. Le travail par le biais de patchs nous semblent difficile et peu efficace vu l'impact des modifications envisagées. Bien cordialement, -- Jean-Mathieu Doléans GLPI-PROJECT.ORG ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] patch d'évolution du NetworkPort
Bonjour, Effectivement, comme je l'indiquais, le patch n'est pas très propre. Dans le patch.V6, il reste des trucs du patch.V4 : dans la version 6 du patch, nous pourrions supprimer les classes WifiPort, AggregatePort et EthernetPort. Mais je n'ai pas osé car il y reste, peut-être, encore des trucs. En fait, pour le patch.V6, le NetworkPort n'est plus une classe abstraite, mais l'unique classe de gestion des ports (qui regroupe tout). Cela explique la présence du NetworkPort::getWifiModes dans cette classe concrète. C'est une question de stratégie. Que proposez-vous : une classe qui gère tous les types de ports (patch.V6) ou une classe par type de réseau (patch.V4) ? Concernant le découpage par étape, voici ce que je propose (bien évidemment, on sautera les étapes que vous ne voulez pas) : * Intégration des PCI_USB_ID dans les cartes et les manufacturiers ; * Mise en place d'une gestion plus fine des jonctions entre les cartes et les ordinateurs ; * Évolution du DeviceNetworCard pour y intégrer les spécificités des réseaux (Ethernet, Wifi,...) ; * Intégration des réseaux (InternetNetwork, FQDN et FQDNlabel) et ajout de la classe CommonImplicitTreeDropdown ; * Création de la classe IPAddresse pour la gestion des adresses IP ; Jusque là, les impacts sur les plugins d'import sont minimes. * Création de la classe NetworkName (Nom réseau suggéré par David, anciennement NetworkNode) en extrayant l'adresse IP du NetworkPort et en supprimant de ce dernier les information de réseau (masque et passerelle) ; * Ajout des NetworkAlias ; * Finalisation des NetworkPort (ajout des information Ethernet, Wifi, ... ou création des classes filles EthernetPort, WifiPort, ...). Damien PS : pas de problème pour échanger par téléphone. On 09/13/11 17:45, MoYo wrote: Salut, Effectivement à force de mettre bout à bout les éléments ca commence à faire un patch énorme qu'il est difficile pour nous de décortiquer. Il intègre en plus des évolutions très diverses : refonte de la gestion des ports (séparation couche internet et liaison), aggregation de ports, gestion du wifi Une solution peut-être serait de voir les évolutions par pallier mais je ne sais pas trop comment cela pourrait être découpé ? Ensuite, j'ai vraiment survolé le patch et il est assez troublant avoir une classe abstraite portent des informations spécifiques à ces enfants. NetworkPort::getWifiModes par exemple. L'abstraction de la classe NetworkPort me semble un peu bizarre vu qu'on y fait des traitements génériques fonction de types filles. Pour la 0.83, c'est encore jouable je pense mais il faudrait arriver à valider complètement les différents éléments petit à petit. Bref, avoir une version finalisée du pallier 1 avant de commencer le second. Il faudrait surement prévoir un moment pour discuter de tout ca et de la façon de procéder (les patchs ce n'est pas une solution pour avancer sur un aussi gros chantier). Cordialement, Julien Dombre Le 12/09/2011 16:26, Damien Touraine a écrit : Bonjour, J'ai un petit problème : à force de mettre bout à bout des petits trucs, j'ai obtenu deux très gros patchs (~ 380K : https://forge.indepnet.net/attachments/960/patch.V4 et https://forge.indepnet.net/attachments/962/patch.V6 appliquablent sur la version 15646 du SVN de GLPI). Ils ne sont pas définitif. Mais, si vous pensez que les modifications que je suggère sont intéressantes à appliquer à GLPI, il me semble difficile, pour vous, de le vérifier en détails avant de l'intégrer à GLPI. Donc, je ne sais pas comment procéder. D'autant plus que cela ne me semble pas être le dossier "chaud" de la 0.83 (ie : validation des nouvelles tab, épuration du code, template sur les tickets, ...). Peut-être ce patch pourrait-il attendre la version 0.84 ou une version ultérieur ? Pour ces patch, j'ai essayé de tenir compte des commentaires de chacun. Ils s'appuient fortement sur les deux pages du wiki que j'ai initié (https://forge.indepnet.net/projects/glpi/wiki/NetworkPortReview et https://forge.indepnet.net/projects/glpi/wiki/Internet_Protocol_resources). Cela facilitera la compréhension de ceux qui souhaitent en valider les concepts et vérifier le patch. Notes que j'ai ajouter des points supplémentaires à la page sur le NetworkPortReview (notamment, sur les effets de bord de mes propositions sur les Device*Card et leur jonction au PC). Je suis conscient que cela chamboule beaucoup de choses pour les plugins, notamment pour l'import d'OCS. Mais je particperai à la mise du coeur de GLPI pour s'adapter à ces changements. Je m'attèlerai, également, à l'outils de migration associé. Ces deux patches sont une ébauche de ce qu'il est possible de faire. Mais ils sont encore pollué par des essais intermédiaires. De plus, ils ne sont par propre : ils ne purgent pas très bien les bases de données lors la suppression de données. Mais ils donnent une bonne idée de ce qu
Re: [Glpi-dev] patch d'évolution du NetworkPort
Salut, Effectivement à force de mettre bout à bout les éléments ca commence à faire un patch énorme qu'il est difficile pour nous de décortiquer. Il intègre en plus des évolutions très diverses : refonte de la gestion des ports (séparation couche internet et liaison), aggregation de ports, gestion du wifi Une solution peut-être serait de voir les évolutions par pallier mais je ne sais pas trop comment cela pourrait être découpé ? Ensuite, j'ai vraiment survolé le patch et il est assez troublant avoir une classe abstraite portent des informations spécifiques à ces enfants. NetworkPort::getWifiModes par exemple. L'abstraction de la classe NetworkPort me semble un peu bizarre vu qu'on y fait des traitements génériques fonction de types filles. Pour la 0.83, c'est encore jouable je pense mais il faudrait arriver à valider complètement les différents éléments petit à petit. Bref, avoir une version finalisée du pallier 1 avant de commencer le second. Il faudrait surement prévoir un moment pour discuter de tout ca et de la façon de procéder (les patchs ce n'est pas une solution pour avancer sur un aussi gros chantier). Cordialement, Julien Dombre Le 12/09/2011 16:26, Damien Touraine a écrit : Bonjour, J'ai un petit problème : à force de mettre bout à bout des petits trucs, j'ai obtenu deux très gros patchs (~ 380K : https://forge.indepnet.net/attachments/960/patch.V4 et https://forge.indepnet.net/attachments/962/patch.V6 appliquablent sur la version 15646 du SVN de GLPI). Ils ne sont pas définitif. Mais, si vous pensez que les modifications que je suggère sont intéressantes à appliquer à GLPI, il me semble difficile, pour vous, de le vérifier en détails avant de l'intégrer à GLPI. Donc, je ne sais pas comment procéder. D'autant plus que cela ne me semble pas être le dossier "chaud" de la 0.83 (ie : validation des nouvelles tab, épuration du code, template sur les tickets, ...). Peut-être ce patch pourrait-il attendre la version 0.84 ou une version ultérieur ? Pour ces patch, j'ai essayé de tenir compte des commentaires de chacun. Ils s'appuient fortement sur les deux pages du wiki que j'ai initié (https://forge.indepnet.net/projects/glpi/wiki/NetworkPortReview et https://forge.indepnet.net/projects/glpi/wiki/Internet_Protocol_resources). Cela facilitera la compréhension de ceux qui souhaitent en valider les concepts et vérifier le patch. Notes que j'ai ajouter des points supplémentaires à la page sur le NetworkPortReview (notamment, sur les effets de bord de mes propositions sur les Device*Card et leur jonction au PC). Je suis conscient que cela chamboule beaucoup de choses pour les plugins, notamment pour l'import d'OCS. Mais je particperai à la mise du coeur de GLPI pour s'adapter à ces changements. Je m'attèlerai, également, à l'outils de migration associé. Ces deux patches sont une ébauche de ce qu'il est possible de faire. Mais ils sont encore pollué par des essais intermédiaires. De plus, ils ne sont par propre : ils ne purgent pas très bien les bases de données lors la suppression de données. Mais ils donnent une bonne idée de ce que je proposes. Quoiqu'il en soit, avant de soumettre la version finale du patch, je repartirai d'une distribution fraiche de GLPI directement issue du SVN. J'y ajouterai les différents points que vous souhaiteriez voir intégrer à GLPI. Je ferai, également, le tri dans le fichier de LANG pour n'y laisser que le strict minimum. D'ailleurs, tout commentaire sur les terminologies serait apprécié (à noter que le "Noeud réseau" sera renommé en "Adresse Internet" à défaut de mieux). Cordialement Damien ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] patch d'évolution du NetworkPort
Le Mon, 12 Sep 2011 16:26:59 +0200 Damien Touraine a écrit: >Bonjour, > >[...] D'ailleurs, tout commentaire >sur les terminologies serait apprécié (à noter que le "Noeud réseau" >sera renommé en "Adresse Internet" à défaut de mieux). > Je pense que "Nom réseau" serait plus parlant aux utilisateurs. David ++ ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
[Glpi-dev] patch d'évolution du NetworkPort
Bonjour, J'ai un petit problème : à force de mettre bout à bout des petits trucs, j'ai obtenu deux très gros patchs (~ 380K : https://forge.indepnet.net/attachments/960/patch.V4 et https://forge.indepnet.net/attachments/962/patch.V6 appliquablent sur la version 15646 du SVN de GLPI). Ils ne sont pas définitif. Mais, si vous pensez que les modifications que je suggère sont intéressantes à appliquer à GLPI, il me semble difficile, pour vous, de le vérifier en détails avant de l'intégrer à GLPI. Donc, je ne sais pas comment procéder. D'autant plus que cela ne me semble pas être le dossier "chaud" de la 0.83 (ie : validation des nouvelles tab, épuration du code, template sur les tickets, ...). Peut-être ce patch pourrait-il attendre la version 0.84 ou une version ultérieur ? Pour ces patch, j'ai essayé de tenir compte des commentaires de chacun. Ils s'appuient fortement sur les deux pages du wiki que j'ai initié (https://forge.indepnet.net/projects/glpi/wiki/NetworkPortReview et https://forge.indepnet.net/projects/glpi/wiki/Internet_Protocol_resources). Cela facilitera la compréhension de ceux qui souhaitent en valider les concepts et vérifier le patch. Notes que j'ai ajouter des points supplémentaires à la page sur le NetworkPortReview (notamment, sur les effets de bord de mes propositions sur les Device*Card et leur jonction au PC). Je suis conscient que cela chamboule beaucoup de choses pour les plugins, notamment pour l'import d'OCS. Mais je particperai à la mise du coeur de GLPI pour s'adapter à ces changements. Je m'attèlerai, également, à l'outils de migration associé. Ces deux patches sont une ébauche de ce qu'il est possible de faire. Mais ils sont encore pollué par des essais intermédiaires. De plus, ils ne sont par propre : ils ne purgent pas très bien les bases de données lors la suppression de données. Mais ils donnent une bonne idée de ce que je proposes. Quoiqu'il en soit, avant de soumettre la version finale du patch, je repartirai d'une distribution fraiche de GLPI directement issue du SVN. J'y ajouterai les différents points que vous souhaiteriez voir intégrer à GLPI. Je ferai, également, le tri dans le fichier de LANG pour n'y laisser que le strict minimum. D'ailleurs, tout commentaire sur les terminologies serait apprécié (à noter que le "Noeud réseau" sera renommé en "Adresse Internet" à défaut de mieux). Cordialement Damien -- Damien TOURAINE - Ingénieur de Recherche CNRS, LIMSI-CNRS Groupe de RV&A "VENISE", (http://www.limsi.fr/venise/) Bat. 508, Universite Paris-Sud 91403 Orsay cedex - +33 1 69 85 81 64 ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
