Utilité du plugin

Est ce qu'un plugin est utile alors que ça doit être développé dans le cœur ?
Voir chantier https://forge.indepnet.net/wiki/glpi/GlpiServers.

MoYo :
- Il faut aussi gérer l'avant / milieu / fond de baie.
- il y a un mélange dans tout ca entre racks et éléments rackables. Quels sont les caractéristiques de qui de quoi ?
- Définir la rackabilité d'un modèle est-ce pertinent ? ne faut-il pas plutôt définir des gabarits d'éléments rackables (ex. serveur ~ 2U profondeur complète, switch : 1U facade) et les associer aux éléments que l'on veux mettre dans le rack ?
- Chaque matériel est spécifique. Même si 2 éléments sont du même modèles ils n'auront pas forcément les même caractéristiques en terme de consommation / dissipation... En effet modèle <> composants inclus.
- En terme de positionnement cf. racktables qui fournit une solution simple de positionnement (même pas besoin de définir les tailles des éléments c'est l'occupation qu'on lui donne dans la baie qui permet de déterminer les dimensions de l'élèment). Les tailles définies peuvent peut-être permettre de faciliter le placement en ne définissant que l'endroit de base (haut gauche du matériel par exemple)

Fonctionnalité actuellement dans le plugin ou à discuter

Gestion des baies (ajout suppression édition)

Une baie est caractérisée par quels attributs ?
  • un nombre d'emplacements ?
  • un poids ( est ce que ça a un intérêt ?)
  • un emplacement dans une salle machine (est ce que ça a une place dans le plugin ou est-ce une info qui pourrait avoir un intérêt dans le cœur ?)
    actuellement c'est une dropdown hiérarchique
  • si choix pertinent' possibilité de faire des créations massives (comme pour les prises réseaux) ?
  • ddurieux : un type de baie (réseau ou serveur car les profondeurs de baies ne sont pas les même, 600 par exemple pour les baies réseau et 1000 pour les baies serveurs)
  • Gabarits de baies : mis en place à l'heure actuelle.
  • un rôle : est ce que ça a un intérêt ? un serveur peut avoir plusieurs rôles : voir plugin applicatif ?

birdy :

En général on caractérise une baie par :
  • sa taille (42, 52U)
  • sa capacité a etre divisée (demi baie quart de baie)
  • sa profondeur (600, 800, 1000 voir meme maitnenant 1200)
  • sa puissance electrique fournie
  • le nombre d'alimentations electrique (redondée ou fourniture totale sur plusieurs bandeaux).
  • Une bonne idée pourrait etre aussi le stockage des codes d'accès (code d'accès de la porte avant, arriere (peut etre au pluriel si baie divisible en 2) ainsi que les codes d'accès éventuel au helpdesk du datacenter (mail, phone).

Matériels dans une baie

  • serveurs
  • matériels réseau
  • périphériques

birdy :

  • bandeaux de renvoit (jarretieres)
  • place perdue (passage de jarretiere optique non souple par exemple)
  • bandeaux de jarretierage téléphonique
  • clavier/ecran
  • placement d'un matériel dans la baie
  • actuellement on gère par 1U. Gestion à faire par 1/3 de U.
  • certaines baies ont des Numéro de U de 1 à 42 par exemple pour une baie de 42U, et il faudrait pouvoir mettre la position de l'équipement dans la baie (exemple un serveur qui fait 4U placé du N° 10 à 13 dans la baie
  • un équipement peut prendre 1, 2, 3, 4, 5U voire même plus si c'est une grosse baie de stockage
  • comment représenter cela de manière simple et lisible ?
  • Faire une vue de face de la baie avec le dessin des contours des équipements avec le nom de l'équipement à l'intérieur

Birdy :

A mon sens il faut le représenter par 1/3 d'U soit pour une baie de 42U 126 carrés. Un serveur 1 U en prendra automatiquement 3. Il n'est pas rare de laisser 1/3 d'U entre chaque machine (de toutes manière les baies n'ont jamais assez de puissante electrique fournie pour la remplir).

Chose a savoir également, beaucoup d'équipements se rackent a l'arriere de la baie et ont une profondeur telle que l'on ne peut plus rien racker devant.

Caractéristiques

  • gestion des alimentations
  • une baie dispose de plusieurs voies d'alimentation
  • pour chaque élément de la baie, on peut indiquer sur quelles alims il est branché (2 seulement)
  • pour l'instant c'est géré par une dropdown est-ce que ça a un intérêt ?
  • Tsmr : en cas de sectorisation des alimentations oui (1 prise mural et une prise onduleur sur tel circuit électrique)
  • birdy : Vital, permet de gerer de la meme maniere un serveur APC et de lier les confs des prises commandées. permet également de savoir quel impact a une coupure electrique (cas de double attachement électrique de serveurs redondés).
  • poids : pour chaque composant on indique un poids. Le total est calculé pour toute la baie. Est ce que l'info a une pertinence ?
  • Tsmr : en cas de déménagement oui
  • Birdy : Dans les fait assez peu.
  • Consommation électrique
  • dissipation calorifique
  • Mobilité de la baie sur roulette ou fixe, celà peut servir si on veut une baie mobile
  • asyd: possibilité d'associer un numéro de ports réseaux et/ou de ports APDUs (permet d'un simple de coup d'oeil sur la fiche serveur de savoir où il est connecté electriquement et au niveau réseau)

Choix du matériel à mettre dans la baie

  • Définition dans la config des types de matériels qui peuvent être ajoutés dans la baie * Association pour un modèle et/ou serveur donné de caractéristiques (poids, dissipation, taille)

Produits existants

OLD : TODOLIST

- Gabarits de modèle pour les ordinateurs (pour utilisation d'un même modèle en masse) et si besoin un gabarit par serveur si chaque serveur est différent

- Combo sous-entités : le replacer = Fait OK

- Uploader la photo d'un modèle de matériel : stocker les images dans files/_plugins/rack et les afficher dans le tableau (maximum 100x100 ou 150x150)

- L'emplacement doit être dropdown comme pour les lieux = Fait OK

- Ajout responsables techniques = Fait OK

- Onglets dans la configuration des modèles = Fait OK

- Nom des classes du plugin : en majuscules

- Stocker la taille en integer (sans le U) = Fait OK

- Filtre préliminaire sur le type d'ordinateurs : type = serveur X, etc. pour la configuration des modèles = Fait OK

- L'emplacement doit être unique pour un lieu donné : filtrer la liste des emplacements

- Reprendre le formulaire des emplacements pour ajout massif

Whishlist (birdy) :

- gerer les attachements IP (Vlans notamment) et les interco par groupe de machine (permet de voir rapidement les services impactés en cas de déplacement d'une machine d'une baie ou d'un switch ? )