Bonjour,
[...]
J'ai encore quelques questions/problèmes.
La création de l'arbre de la topologie réseau (ie : retrouver les
dépendances de réseaux) n'est pas réalisable lors de la migration car
on a besoin d'un contexte complet (ie : administrateur logger) pour
faire jouer les mécanismes automatiques de hiérarchisation. Est-il
possible d'ajouter une tâche à executer automatique une fois juste
après le log d'un "big" administrateur ? À défaut, j'ai mis un lien
dans l'outil de nettoyage de migration. Même si c'est quelque chose
qui sera très util, ce n'est pas primordial si la hiérarchie des
réseaux n'est pas présente dès le début : GLPI n'en a jamais eu
jusqu'à maintenant.
Quelles sont les données du contexte qui sont nécessaire ?
Il n'y a pas moyen de les charger et de les utiliser au moment de
lamigration ?
Le mécanisme de hiérarchisation des réseaux repose sur les méthodes
prepareInputForUpdate/prepareInputForAdd pour la mise à jour du champs
"getForeignKeyField()" et sur les méthodes post_addItem/post_updateItem
pour réorganiser les noeuds fils (ie : rattacher les bons fils au noeud
courant et détacher les anciens fils pour les rattacher ầ l'ancien père).
C'est assez complexe. Le plus simple et le plus propre est d'appeler
CommonDBTM::add ou CommonDBTM::update (comme le fait la méthode
IPNetwork::recreateTree()). C'est ce qui requiert la mise en place d'un
contexte complet.
Je n'aime pas laisser des tâches en suspend, mais cette hierarchisation
n'est pas une nécessité absolue lors de la migration. Il faut noter que
dans la plupart des cas il n'y aura, au plus, qu'une faible
hiérarchisation des réseaux. En effet, les réseaux sont créés sur la
base des NetworkPort qui ne représentent que des réseaux physique
(adressable) et donc, des plages d'adresses différentes si les
administrateurs n'ont pas intégrés les plages de routage dans GLPI.
J'ai un problème plus épineux, justement sur les
glpi_networknames_ipnetworks (ou glpi_ipnetworks_networknames :D). En
effet, dans un premier temps, je pensais appliquer le même mécanisme
qu'avec la hiérarchie des réseaux (lien dans l'outil de nettoyage de
migration). Mais lorsque je le lance sur une base de donnée
volumineuse (~ 70.000 NetworkPort), au bout d'un certains temps, cela
explose à cause des allocations mémoires (avec 8Go de mémoire, je
pensais être à l'abri de ce genre de message :D). Pour ceux que cela
intéresse, le code est dans
NetworkName_IPNetwork::recreateAllConnexities() (cf. commit 17139).
Je pense possible de faire cette création lors de la migration. Mais
si cela explose à cet endroit, pourquoi cela n'exploserait pas lors
de la migration ?
Ce n'est pas vraiment normal que ca explose.
Il faudrait voir pourquoi.
Je vais essayer de le transférer dans la migration, pour voir si cela
passe mieux.
Autant la hiérarchisation des réseau n'est pas une obligation, du moins
dans un premier temps, autant, il est beaucoup plus fondamental d'avoir
ces liens en les NetworkName et les IPNetwork.
[...]
Damien
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
