Integration of server scope 3 impacts in project dashboards about boaviztapi HOT 13 CLOSED

Hello,

On arrive à la fin du mois. J'arrive à un truc plus sympa. C'est à dire :

Je prends un répertoire servers (par exemple) :
└── 2020-11-10.json
└── 2020-11-11.csv
└── 2021-03-10.csv
└── 2021-07-10.json

Je mets plein de fichiers dedans csv ou json mélangés qui contiennent des listes de serveurs et je construis un grand fichier avec la liste des serveurs par date.
Je sais pas si c'est pertinent, j'ai pas encore réfléchi à l'exploitation.

Mais l'idée est qu'on puisse compiler de la donnée qui puisse venir de plusieurs sources ou formats sans se poser trop de questions. Puis de récupérer ça par date sur le front pour faire de la comparaison dans le temps.

Je pense que j'en aurai plus début janvier. Car si trop de données se mélangent, je suis pas sur qu'on puisse exploiter correctement.

from boaviztapi.

From @bertrandkeller

J'essaye d'utiliser Eleventy pour constituer mon objet à exploiter.

Je ne sais pas comment stocker au mieux les fichiers "inventaire", je réfléchis pour le moment ça donne
server
└── nom-serveur-1.json
└── nom-serveur-2.json

from boaviztapi.

Surement la meilleure manière en effet.
On réfléchit à supporter des CSV en entré, mais ça sera sûrement quand on s'attaquera à une vue système d'information.
Si tu veux un exemple qui fonctionne sur la version qu'on sort cet aprem : #6 (comment)

L'exemple suit le modèle ci-dessus

from boaviztapi.

From @bertrandkeller

On peut aussi construire un CSV avec des intitulés sous cette forme : configuration:cpu:number

On peut utiliser ce package NPM pour convertir en format structuré :
https://www.npmjs.com/package/treeize

Ce qui impliquerait quand même de travail en priorité sur un fichier unique avec plein de serveurs, plutôt que plein de fichiers éclatés.

Pour le CSV, ça donnerait un truc comme ça :

"model:brand","model:name","model:type","model:year","configuration:cpu:number","configuration:cpu:core_number","configuration:cpu:die","configuration:cpu:manufacturer","configuration:cpu:model","configuration:cpu:cpu_family","configuration:ram:capacity","configuration:ram:quantity","configuration:ram:die","configuration:ram:manufacturer","configuration:ram:model","configuration:ram:cpu_family","configuration:ssd:capacity","configuration:ssd:quantity","configuration:ssd:die","configuration:ssd:manufacturer","configuration:ssd:model","configuration:hdd:number","configuration:hdd:manufacturer","configuration:hdd:model","configuration:power_supply:weight","configuration:power_supply:quantity"
"Dell","R740","rack",2020,2,24,0.245,"Intel","",,32,12,1.79,"Samsung","","Corsaire",400,1,50.6,"Samsung","",0,"Samsung","",10,1

Ma lib node n'a pas l'air d'aimer les double quote sur les champs. Donc, ça marche mieux sans double quote.
J'arrive à récupérer le JSON associé.

Si fichier json dans un répertoire, j'envoie le contenu de ce json pour la requête ;
Si csv présent dans le répertoire, je converti le csv, et je m'en sers pour la requête.

Mais l'accès au serveur de test a l'air de ne plus marcher.

model:brand,model:name,model:type,model:year,configuration:cpu:number,configuration:cpu:core_number,configuration:cpu:die,configuration:cpu:manufacturer,configuration:cpu:model,configuration:cpu:cpu_family,configuration:ram:capacity,configuration:ram:quantity,configuration:ram:die,configuration:ram:manufacturer,configuration:ram:model,configuration:ram:cpu_family,configuration:ssd:capacity,configuration:ssd:quantity,configuration:ssd:die,configuration:ssd:manufacturer,configuration:ssd:model,configuration:hdd:number,configuration:hdd:manufacturer,configuration:hdd:model,configuration:power_supply:weight,configuration:power_supply:quantity
Dell,R740,rack,2020,2,24,0.245,Intel,,,32,12,1.79,Samsung,,Corsaire,400,1,50.6,Samsung,,0,Samsung,,10,1

from boaviztapi.

Hum on a publié ce matin dessus la V0.
Si tu veux voir la doc tu as des exemples de JSON qui fonctionnent bien :
http://149.202.185.115/API/server_route/

from boaviztapi.

From @bertrandkeller

Ok,

J'obtiens bien le résultat. Je continuerai la semaine prochaine.

J'ai donc script Node. Qui fonctionne avec eleventy et que je dois paramétrer pour fonctionner avec goHugo.
Il génère un objet pour eleventy ou peut écrire un fichier JSON pour Hugo.

Il faut ajouter une colonne au CSV pour avoir le nom de serveur. Ensuite. suffira de savoir ce que je fais avec ces données.

J'ai les informations en entrée que je peux exploiter ; plus celle de l’API que je peux afficher aussi.
Une petite liste de serveurs avec leur impact (plus le total :: la somme de tous).

C'est quoi exactement : gwp, pe, adp ?

from boaviztapi.

from boaviztapi.

Bon, j'ai fait un script qui vaut ce qui vaut, mais qui devait prendre en compte et des json ou un csv. J'ai eu pas mal de soucis avec le nouveau json qui propose des array pour la ram et le disk.

Donc je passe par le npm csvtojson. Pour parser un csv de ce type :

name,model.manufacturer,model.name,model.type,model.year,configuration.cpu.units,configuration.cpu.core_units,configuration.cpu.die_size_per_core,configuration.ram.0.units,configuration.ram.0.capacity,configuration.ram.0.density,configuration.disk.0.units,configuration.disk.0.type,configuration.disk.0.capacity,configuration.disk.0.density,configuration.power_supply.units,configuration.power_supplyunit_weight
server csv 1,Dell,R740,rack,2020,2,24,0.245,12,32,1.79,1,ssd,400,50.6,2,2.99
server csv 2,Dell,R740,rack,2021,2,24,0.245,12,32,1.79,1,ssd,400,50.6,4,2.99

On peut donc mettre autant de ram et de disk que souhaité en ajoutant des 1, 2, 3… dans les entêtes. C'est pas hyper lisible mais ça permet de bosser avec un feuille de calcul sous excel.

Je peux maintenant essayer de voir ce que je peux afficher avec le résultat de l’API.

Le Script peut écrire les données dans un fichier json. Je dois donc ajouter la gestion d’arguments pour l'utilisation avec goHugo (avec la prise en compte du chemin du fichier source).

from boaviztapi.

Super merci pour ces informations.
En effet, le format liste pour les composants posent plusieurs problèmes, mais permettent plus de modularité d'où ce choix.

Les applis utilisant l'API peuvent considérer qu'un serveur n'a qu'un seul type de RAM ou de DISK pour chaque serveur pour plus de facilité.

Nous travaillions sur une option "verbose" pour renvoyer les données prisent en hypothèse quand une donnée est manquante et qui affiche l'impact de chacun des composants => #8

from boaviztapi.

On a notre 3ᵉ hackathon le 13 et 14 janvier si tu as l'occasion de nous présenter tes résultats ça pourra intéresser l'équipe !

from boaviztapi.

Hello, j'ai pas trop avancé sur le sujet depuis 1 mois.
Mais si besoin je peux faire une démo demain.

from boaviztapi.

On a une démo de l'API prévu à 10h30 si tu souhaite te joindre à nous.
Je t'envois les infos par mail.

from boaviztapi.

Le serveur de dev à dû être changé avec un monté de version intermédiaire avant la publication de la V1 :

Documentation interactive : http://149.202.161.61:5000/docs
Dev API server: http://149.202.161.61:5000

On attend un nom de domaine très bientôt pour éviter ces problèmes.

Le route v1/server/bottom-up existe toujours, mais on conseille d'utiliser la route v1/server/ qui fournit la même fonction (nouveau nom de la route)

from boaviztapi.