# Rapport Hermes — 2026-06-06_10-30
> Branche : `hermes/daily-work` · Fichiers analysés : 5

---
## Résumé
- ✅ À jour : 5
- ⚠️  À améliorer : 0

## ✅ `admin/install/README.md` — 8/10

**Statut** : à_jour  
**Résumé** : Document d'installation structuré avec ordre de déploiement clair et état des services mis à jour le 2026-06-05  

**Problèmes :**
- L'absence d'explications sur l'inactivation du service litellm malgré la configuration attendue
- Le statut 'activating' de qdrant n'est pas détaillé (retard/erreur de démarrage ?)

**Suggestions :**
- Ajouter une note explicative sur l'inactivation du service litellm
- Préciser le statut de qdrant (ex: 'démarrage en cours depuis X minutes')
- Inclure des pistes de diagnostic pour les services en anomalie

**État réel connu de Hermes :**  
storage-01 fonctionne comme prévu, gpu-01 dépendant de la réussite de qdrant, cluster k8s opérationnel avec des services critiques actifs

---

## ✅ `admin/install/gpu-01.md` — 7/10

**Statut** : à_jour  
**Résumé** : Document d'installation complet pour gpu-01 avec des sections clés, mais avec des lacunes dans les vérifications post-install et le playbook Ansible.  

**Problèmes :**
- La section 'Vérifications post-install' est vide et manque de détails sur les tests nécessaires après l'installation
- Le playbook Ansible dans l'inventaire YAML est incomplet (section 'gpu_hosts' tronquée)
- Aucune mention des dépendances logicielles spécifiques à ROCm ou des paramètres de compilation
- Le workaround HSA_OVERRIDE_GFX_VERSION est mentionné mais pas expliqué en détail

**Suggestions :**
- Ajouter une section détaillée de vérifications post-install (tests de latence, benchmark GPU, tests d'inférence)
- Compléter le fichier d'inventaire Ansible avec les hôtes configurés
- Inclure des notes sur la configuration requise pour ROCm (versions spécifiques, dépendances logicielles)
- Expliciter les étapes pour valider le fonctionnement du workaround gfx1031

**État réel connu de Hermes :**  
Le matériel gpu-01 est opérationnel avec ROCm via le workaround gfx1031, mais les vérifications post-install ne sont pas documentées

---

## ✅ `admin/install/kubernetes.md` — 8/10

**Statut** : à_jour  
**Résumé** : Document complet et structuré décrivant l'installation d'un cluster Kubernetes avec Talos Linux, incluant les architectures, prérequis, étapes d'installation et bonnes pratiques. Les sections sont bien organisées mais manque de détails concrets sur certaines étapes.  

**Problèmes :**
- La section 'Pièges et erreurs rencontrés' est vide et ne contient pas d'exemples concrets
- Manque de détails sur les tâches Ansible spécifiques à exécuter (ex: playbook exact)
- La configuration NFS provisioner est mentionnée mais pas détaillée
- Pas de version précise des outils mentionnés (ex: Talos v1.13.0 vs latest)

**Suggestions :**
- Ajouter des exemples concrets dans la section 'Pièges et erreurs'
- Spécifier les tâches Ansible exactes à exécuter
- Détailler les étapes de configuration NFS avec des commandes ou paramètres
- Mettre à jour les versions des outils avec des balises semántiques (ex: v1.13.0 plutôt que 'latest')

**État réel connu de Hermes :**  
ok

---

## ✅ `admin/install/storage-01.md` — 8/10

**Statut** : à_jour  
**Résumé** : Document complet et structuré avec des étapes claires pour l'installation de storage-01, mais nécessite des améliorations dans les détails techniques et les vérifications post-installation.  

**Problèmes :**
- Manque de détails sur la configuration RAID5 (monitoring SMART, répartition des disques)
- Les commandes SSH utilisent sudo sans préciser les droits requis
- Le playbook Ansible n'indique pas les chemins exacts des répertoires
- Aucune vérification spécifique des services post-installation (état des conteneurs, santé RAID)
- La section des pièges manque des exemples concrets de résolution

**Suggestions :**
- Ajouter des étapes pour tester la résilience RAID avec smartctl
- Préciser les permissions requises pour les commandes SSH
- Indiquer les chemins absolus du repo Ansible dans le playbook
- Ajouter des vérifications automatiques des services après déploiement
- Inclure des exemples de logs d'erreur et leur résolution

**État réel connu de Hermes :**  
Le matériel RAID5 fonctionne avec des erreurs I/O passées, les services Hermes/LiteLLM sont opérationnels, le playbook Ansible a été exécuté avec succès dans le cluster

---

## ✅ `admin/k8s/argocd.md` — 8/10

**Statut** : à_jour  
**Résumé** : Documentation complète sur l'installation et l'utilisation d'ArgoCD pour GitOps, avec des étapes claires et des exemples de fichiers, mais quelques améliorations possibles.  

**Problèmes :**
- La version Helm 9.5.14 mentionnée pourrait être obsolète (vérifier la dernière version stable)
- Aucune mention des vérifications post-installation pour valider le fonctionnement d'ArgoCD
- Le fichier d'exemple pour l'Application ArgoCD manque le paramètre 'project' dans la section 'spec'
- Le script de suppression du secret initial ne vérifie pas si le secret existe avant de le supprimer
- Aucune mention des règles de sécurité pour les clés SSH dans le secret argocd-repo-funk-lab

**Suggestions :**
- Mettre à jour la version Helm avec la dernière stable (ex: 3.7.x)
- Ajouter une section de vérification post-installation (ex: 'argocd app list')
- Compléter l'exemple d'Application avec 'project: default' dans la spécification
- Ajouter un check 'kubectl get secret argocd-initial-admin-secret -n argocd --ignore-not-found' avant suppression
- Documenter les bonnes pratiques pour les clés SSH (ex: permissions 600, nommage des fichiers)

**État réel connu de Hermes :**  
Le composant est actif dans le cluster Funk, avec des applications déployées dans le namespace 'argocd'. Le repo Git est configuré avec succès, mais les validations post-installation devraient être ajoutées pour assurer la fiabilité.

---

