Re: [Glpi-dev] Evolution synchro/import
Salut, le but était de pouvoir supprimer des éléments et qu'ils ne reviennent pas à la prochaine synchro. Exemple je supprime des périphériques pour ne garder que le clavier et la souris mais sans vouloir le reste. ++ Julien Le 09/01/2013 18:03, Tsmr a écrit : Pareil pour moi. Il est indéniable que modifier le user affecté à un pc pour le fixer au lieu de récupérer celui d'OCS est une fonction obligatoire dans les locks (donc le verrouillage des champs du pc : OUI) Pour autant, quel est l'intérêt de verrouiller des composants / connexions à des Moniteurs, Périphériques, Impirmantes / Logiciels / IP, là je suis aussi septique sur le but initial Je suis aussi preneur d'exemple. -- Tsmr Xavier CAILLAUD ___ 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] Evolution synchro/import
Bonjour à tous, On 19/01/2012 08:34, Remi Collet wrote: Une proposition d'évolution pour la gestion des éléments importés Exemple, table glpi_computervirtualmachines Ajout de 2 champs - is_dynamic = importé - is_deleted = supprimé (verrouillé dans ce cas) Lors de la suppression si is_dynamic=1 = passer is_deleted=1 (sinon purger, comme d'hab) Gestion des verrous VM verrouillées : is_dynamic=1 ET is_deleted=1 Deverrouiller = is_deleted=0 Lors de l'import OCS, au lieu de prendre le contenu de glpi_ocslinks.import_vm, on fait un SELECT ... WHERE computers_id=xx AND is_dynamic Avantages : - méthode standard déjà utilisée pour les utilisateurs (droits et groupes) - méthode indépendante de l'outil d'import (Fusion doit pouvoir l'utiliser, à confirmer, David ?) - gestion plus légère glpi_ocslinks, je trouve ça lourd, avec 2Gio (sur 13Gio), c'est la plus grosse table chez nous, après glpi_logs (9Gio) et avant les install (1.4Gio) - moins d'UPDATE (maj de glpi_ocslinks) Inconvénients : - plus de SELECT pendant la synchro, mais bon, on utilise un index. - ce que j'ai probablement raté Ensuite, à généraliser aux autres données : - glpi_computers_device* (là de toutes manières faut revoir tout le schéma pour les champs specificity) - glpi_computerdisks - glpi_computers_softwareversions - glpi_computers_items (monitor, peripheral, printer et donc phone, même si pas utiliser par OCS) J'ai un peu de mal à voir au niveau migration. Dans import_printer par exemple on a des enregistrement qui n'existent plus dans glpi_computers_items, donc comment garder le verrou : recréer les enregistrements et mettre is_dynamic=1 is_deleted=1 ? Cordialement, Walid. ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Evolution synchro/import
Le 20/12/2012 14:43, Walid Nouh a écrit : Bonjour à tous, On 19/01/2012 08:34, Remi Collet wrote: Une proposition d'évolution pour la gestion des éléments importés Exemple, table glpi_computervirtualmachines Ajout de 2 champs - is_dynamic = importé - is_deleted = supprimé (verrouillé dans ce cas) Lors de la suppression si is_dynamic=1 = passer is_deleted=1 (sinon purger, comme d'hab) Gestion des verrous VM verrouillées : is_dynamic=1 ET is_deleted=1 Deverrouiller = is_deleted=0 Lors de l'import OCS, au lieu de prendre le contenu de glpi_ocslinks.import_vm, on fait un SELECT ... WHERE computers_id=xx AND is_dynamic Avantages : - méthode standard déjà utilisée pour les utilisateurs (droits et groupes) - méthode indépendante de l'outil d'import (Fusion doit pouvoir l'utiliser, à confirmer, David ?) - gestion plus légère glpi_ocslinks, je trouve ça lourd, avec 2Gio (sur 13Gio), c'est la plus grosse table chez nous, après glpi_logs (9Gio) et avant les install (1.4Gio) - moins d'UPDATE (maj de glpi_ocslinks) Inconvénients : - plus de SELECT pendant la synchro, mais bon, on utilise un index. - ce que j'ai probablement raté Ensuite, à généraliser aux autres données : - glpi_computers_device* (là de toutes manières faut revoir tout le schéma pour les champs specificity) - glpi_computerdisks - glpi_computers_softwareversions - glpi_computers_items (monitor, peripheral, printer et donc phone, même si pas utiliser par OCS) J'ai un peu de mal à voir au niveau migration. Dans import_printer par exemple on a des enregistrement qui n'existent plus dans glpi_computers_items, donc comment garder le verrou : recréer les enregistrements et mettre is_dynamic=1 is_deleted=1 ? Si les enregistrements n'existent plus tu ne peux pas faire grand chose. 2 solutions : - Tu les ignorent pour le moment. Les éléments remonteront au prochain import et devront être supprimés de nouveau. - Tu gardes en base dans le plugin OCS les éléments supprimés et il faudra au moment de la prochaine synchro quand ils remonteront les créés et les flagguer comme supprimés. Ca risque de complexifier pas mal la gestion. ++ Julien ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Evolution synchro/import
Le 30/01/2012 14:40, Damien Touraine a écrit : Salut, Bonjour Rémi, C'est Remi ;) J'aimerais comprendre un petit peu plus ce que tu proposes. Ne serait-ce que pour filer un coup de main pour les NetworkPort (ou plus, ou moins, selon vos souhaits/besoins). En fait, c'est le lien entre les éléments importés et la base OCS que j'ai du mal à cerner. Jusqu'à maintenant, l'existence du lien entre GLPI et OCS était inclue dans la base glpi_ocslinks. Est-ce bien cela ? Si j'ai bien compris, tu proposes de transférer l'information de ce lien directement dans la base concernée avec des champs prévus à cet effet (le contenu de glpi_ocslink.import_vm = glpi_computervirtualmachines.is_dynamic, glpi_computervirtualmachines.is_deleted). Est-ce bien cela ? Oui Ainsi, il y aurait disparition complète de glpi_ocslink. Est-ce bien cela ? Non, il sera conservé, pour les liens (correspondance des id) et le verrouillage des champs. Bien sur déplacer dans le plugin OCS + ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Evolution synchro/import
Le 30/01/2012 16:12, Damien Touraine a écrit : Bonjour, [...] J'aimerais comprendre un petit peu plus ce que tu proposes. Ne serait-ce que pour filer un coup de main pour les NetworkPort (ou plus, ou moins, selon vos souhaits/besoins). En fait, c'est le lien entre les éléments importés et la base OCS que j'ai du mal à cerner. Jusqu'à maintenant, l'existence du lien entre GLPI et OCS était inclue dans la base glpi_ocslinks. Est-ce bien cela ? Si j'ai bien compris, tu proposes de transférer l'information de ce lien directement dans la base concernée avec des champs prévus à cet effet (le contenu de glpi_ocslink.import_vm = glpi_computervirtualmachines.is_dynamic, glpi_computervirtualmachines.is_deleted). Est-ce bien cela ? Oui Ainsi, il y aurait disparition complète de glpi_ocslink. Est-ce bien cela ? Non, il sera conservé, pour les liens (correspondance des id) et le verrouillage des champs. Bien sur déplacer dans le plugin OCS Mes connaissances dans le plugin OCS sont floues. S'agit-il bien du lien entre les id des objets dans la base de donnée OCS et ceux dans la base de donnée GLPI ? Oui mais pas seulement, il y a d'autres info spécifiques OCS - server_id - device_id (un truc du genre TOTO-2012-01-01) - ocsid (l'ID elle même) - date d'import - date d'inventaire - etc... Les besoins d'un autre plugin d'import (Fusion, p.e.) seront différents Donc la table ocslinks garde tout son sens Si c'est bien cela, j'ai pensé à un truc qui pourrait être beaucoup plus simple et plus efficace. Mais peut-être est-ce déjà prévu pour fonctionner comme cela. Sinon, cela risque de heurter les plus orthodoxes. Ma proposition : lors de l'installation du plugin OCS, on ajoute un champs plugin_OCS_id dans chacune des tables dont les objets peuvent être liés avec un objet OCS (ie : glpi_computers, Non, vraiment pas glop comme solution glpi_computers_device*, glpi_networkport*, ...). Le champs is_dynamique serait remplacé par le test : (plugin_OCS_id 0). Le is_deleted serait nommé plugin_OCS_is_deleted. Mais on pourrait aussi regarder si plugin_OCS_id n'est pas nul, et que l'objet correspondant n'existe plus dans la base de donnée OCS. l'id OCS pour les éléments autres que l'ordinateur n'a aucun intérêt, il change à chaque inventaire. Seul l'id GLPI a du sens, ensuite on compare les autres informations remontées par OCS (UUID pour les VM, nom+version pour les logiciels, etc) ++ Cela simplifierait grandement les liens et les recherches. Je pense que nous pourrions nous en sortir avec un mapping intelligent de type entre OCS et GLPI. Petit point noir : lors de la désinstallation du plugin OCS (pas la désactivation), il faudra supprimer ces champs. Cela signifie une perte de tous les liens. Ce plugin est-il souvent désinstallé ? Damien, le bourrin de service. ___ 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] Evolution synchro/import
Le Thu, 19 Jan 2012 08:34:12 +0100 Remi Collet fed...@famillecollet.com a écrit: Une proposition d'évolution pour la gestion des éléments importés Exemple, table glpi_computervirtualmachines Ajout de 2 champs - is_dynamic = importé - is_deleted = supprimé (verrouillé dans ce cas) Lors de la suppression si is_dynamic=1 = passer is_deleted=1 (sinon purger, comme d'hab) Gestion des verrous VM verrouillées : is_dynamic=1 ET is_deleted=1 Deverrouiller = is_deleted=0 Lors de l'import OCS, au lieu de prendre le contenu de glpi_ocslinks.import_vm, on fait un SELECT ... WHERE computers_id=xx AND is_dynamic Avantages : - méthode standard déjà utilisée pour les utilisateurs (droits et groupes) - méthode indépendante de l'outil d'import (Fusion doit pouvoir l'utiliser, à confirmer, David ?) - gestion plus légère glpi_ocslinks, je trouve ça lourd, avec 2Gio (sur 13Gio), c'est la plus grosse table chez nous, après glpi_logs (9Gio) et avant les install (1.4Gio) - moins d'UPDATE (maj de glpi_ocslinks) Inconvénients : - plus de SELECT pendant la synchro, mais bon, on utilise un index. - ce que j'ai probablement raté Ensuite, à généraliser aux autres données : - glpi_computers_device* (là de toutes manières faut revoir tout le schéma pour les champs specificity) - glpi_computerdisks - glpi_computers_softwareversions - glpi_computers_items (monitor, peripheral, printer et donc phone, même si pas utiliser par OCS) - glpi_networkports (qu'il faut réécrire suite aux travaux de Damien) Il me semblerait intéressant de réaliser ce chantier en pré-requis à la sortie d'OCS en plugin. Voila, pour avis... (oui, c'est un gros chantier, avec une très grosse migration) Remi. C'est bon pour moi, excepté que le is_deleted = supprimé (verrouillé dans ce cas) n'est pas aproprié par rapport aux is_deleted des autres items, de ce fait, je mettrai plutôt quelquechose du genre is_locked David ++ ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
[Glpi-dev] Evolution synchro/import
Une proposition d'évolution pour la gestion des éléments importés Exemple, table glpi_computervirtualmachines Ajout de 2 champs - is_dynamic = importé - is_deleted = supprimé (verrouillé dans ce cas) Lors de la suppression si is_dynamic=1 = passer is_deleted=1 (sinon purger, comme d'hab) Gestion des verrous VM verrouillées : is_dynamic=1 ET is_deleted=1 Deverrouiller = is_deleted=0 Lors de l'import OCS, au lieu de prendre le contenu de glpi_ocslinks.import_vm, on fait un SELECT ... WHERE computers_id=xx AND is_dynamic Avantages : - méthode standard déjà utilisée pour les utilisateurs (droits et groupes) - méthode indépendante de l'outil d'import (Fusion doit pouvoir l'utiliser, à confirmer, David ?) - gestion plus légère glpi_ocslinks, je trouve ça lourd, avec 2Gio (sur 13Gio), c'est la plus grosse table chez nous, après glpi_logs (9Gio) et avant les install (1.4Gio) - moins d'UPDATE (maj de glpi_ocslinks) Inconvénients : - plus de SELECT pendant la synchro, mais bon, on utilise un index. - ce que j'ai probablement raté Ensuite, à généraliser aux autres données : - glpi_computers_device* (là de toutes manières faut revoir tout le schéma pour les champs specificity) - glpi_computerdisks - glpi_computers_softwareversions - glpi_computers_items (monitor, peripheral, printer et donc phone, même si pas utiliser par OCS) - glpi_networkports (qu'il faut réécrire suite aux travaux de Damien) Il me semblerait intéressant de réaliser ce chantier en pré-requis à la sortie d'OCS en plugin. Voila, pour avis... (oui, c'est un gros chantier, avec une très grosse migration) Remi. * Le contenu de ce courriel et ses éventuelles pièces jointes sont confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire. Attention : L'organisme de l'émetteur du message ne pourra être tenu responsable de l'altération du présent courriel. Il appartient au destinataire de vérifier que les messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses éventuelles pièces jointes sont celles de l'émetteur. Elles ne reflètent pas la position de l'organisme sauf s'il en est disposé autrement dans le présent courriel. ** ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
