Ajout d'un watchdog #29

Closed
opened 2026-05-01 20:56:14 +00:00 by nicolas.boufideline · 5 comments

En gros il faut ajouter un system qui check l'etat des elements.

En gros il faut ajouter un system qui check l'etat des elements.
Author
Owner

toujours en test

toujours en test
Author
Owner

me reste quelque ellements a confirmer

me reste quelque ellements a confirmer
Author
Owner

je ne suis toujours pas sur que le denier commit sois valide

je ne suis toujours pas sur que le denier commit sois valide
Author
Owner

nop toujours pas et ca m'embete

nop toujours pas et ca m'embete
Author
Owner

Livré et vérifié sur binaire réel. 67 tests, couverture 86,3 %, suite complète verte y compris -race.

Forme — goroutine périodique, lecture seule : elle observe et notifie, ne répare jamais. Seul l'état running est vérifié — ni les états transitoires ni error/deleted, pour éviter les faux positifs.

Décision anti-flood — interface de notification nue, répétition assumée : Notify est appelée à chaque tick tant que l'écart persiste, le watchdog reste sans état. Le filtrage est la responsabilité des notifiers ou de l'alerting en aval. Un test verrouille cette décision : si quelqu'un ajoute une déduplication silencieuse, il casse.

Quatre corrections apportées à la spec initiale, trouvées en lisant le code

  1. La config utilise viper : des tags yaml: n'auraient rien bindé, le watchdog ne serait jamais parti, en silence. Tags mapstructure:.
  2. Le nom d'unit dnsmasq est <vpc>_<bridge>, soit dnsmasq@vp-admin_br-000000.service, et non <vpc>_<subnet>.
  3. Le mode change les interfaces à vérifier : en mode bridge, ni bridge host ni interface vxlan — sans ça, faux positif sur chaque subnet bridge.
  4. subnetID vient du nom du subnet, pas de TrimPrefix(local_iface, "br-") — local_iface est une interface distincte.

Décisions de conception

  • vpcIfaceNames ne panique pas là où vpc.CreateVPC le fait : le watchdog itère sur le contenu de la base, une panique dans sa goroutine tuerait tout l'agent.
  • Un état corrompu en base est notifié, pas remonté en erreur : sinon une seule clé illisible aveuglerait le watchdog sur toutes les ressources suivantes.
  • unitChecker en interface : une seule connexion D-Bus par tick au lieu d'une par ressource, et la vérification d'unit devient testable hors Linux.
  • Connexion D-Bus ouverte et fermée à chaque tick plutôt que mise en cache : une connexion cachée devient obsolète si systemd redémarre. Échec signalé une seule fois (drapeau dbusDown), sinon 1440 avertissements par jour.
  • interval <= 0 retombe sur 60 s : time.NewTicker panique sur une durée nulle, un interval_seconds oublié aurait empêché l'agent de démarrer.
  • QMP et scope systemd sont vérifiés tous les deux : leur croisement est un diagnostic — scope actif + QMP muet = QEMU figé ; scope absent + QMP muet = VM disparue.
  • local_iface n'est pas vérifié : interface préexistante que le subnet n'a pas créée.
  • Défaut enabled: false mais true dans config.exemple.yml : un host qui monte de version ne change pas de comportement, un déploiement neuf a le watchdog actif.

Durcissement au passage — pkg/systemd.Status faisait trois assertions props[...].(string) sans , ok. Le watchdog interroge des noms d'unit arbitraires à chaque tick depuis une goroutine : une propriété manquante aurait paniqué et tué l'agent.

Risque tracé, décision de ne rien changer — pkg/systemd.New() utilise context.Background() sans timeout, alors que le même fichier borne Status (5 s) et job (30 s). Si le socket D-Bus accepte sans répondre, le tick ne rend jamais la main et le watchdog meurt en silence — le pire mode de défaillance pour un composant de surveillance. Concerne aussi quatre appelants existants : subnet/create.go, subnet/delete.go et metadata/handle.go (deux fois), où une création de subnet ou un démarrage de VM peut se figer. Correctif si on y revient : context.WithTimeout dans New(), ou un NewContext(ctx) réservé au watchdog.

Reste à couvrir sous Linux — tout le chemin après netns.Exist() == true : checkSubnetNetns 33 %, checkVPC 47 %, checkVMTap 69 %, linkProblem 60 %, units 60 %. Le cas « QMP répond » est testable sur macOS avec un faux serveur sur socket Unix.

Livré et vérifié sur binaire réel. 67 tests, couverture 86,3 %, suite complète verte y compris `-race`. **Forme** — goroutine périodique, **lecture seule** : elle observe et notifie, ne répare jamais. Seul l'état `running` est vérifié — ni les états transitoires ni `error`/`deleted`, pour éviter les faux positifs. **Décision anti-flood** — interface de notification **nue**, répétition assumée : `Notify` est appelée à chaque tick tant que l'écart persiste, le watchdog reste sans état. Le filtrage est la responsabilité des notifiers ou de l'alerting en aval. Un test verrouille cette décision : si quelqu'un ajoute une déduplication silencieuse, il casse. **Quatre corrections apportées à la spec initiale, trouvées en lisant le code** 1. La config utilise **viper** : des tags `yaml:` n'auraient rien bindé, le watchdog ne serait jamais parti, en silence. Tags `mapstructure:`. 2. Le nom d'unit dnsmasq est `<vpc>_<bridge>`, soit `dnsmasq@vp-admin_br-000000.service`, et non `<vpc>_<subnet>`. 3. **Le mode change les interfaces à vérifier** : en mode bridge, ni bridge host ni interface vxlan — sans ça, faux positif sur *chaque* subnet bridge. 4. `subnetID` vient du **nom du subnet**, pas de `TrimPrefix(local_iface, "br-")` — `local_iface` est une interface distincte. **Décisions de conception** - `vpcIfaceNames` ne panique pas là où `vpc.CreateVPC` le fait : le watchdog itère sur le contenu de la base, une panique dans sa goroutine tuerait tout l'agent. - Un état corrompu en base est **notifié**, pas remonté en erreur : sinon une seule clé illisible aveuglerait le watchdog sur toutes les ressources suivantes. - `unitChecker` en interface : une seule connexion D-Bus par tick au lieu d'une par ressource, et la vérification d'unit devient testable hors Linux. - Connexion D-Bus **ouverte et fermée à chaque tick** plutôt que mise en cache : une connexion cachée devient obsolète si systemd redémarre. Échec signalé **une seule fois** (drapeau `dbusDown`), sinon 1440 avertissements par jour. - `interval <= 0` retombe sur 60 s : `time.NewTicker` panique sur une durée nulle, un `interval_seconds` oublié aurait empêché l'agent de démarrer. - **QMP et scope systemd sont vérifiés tous les deux** : leur croisement est un diagnostic — scope actif + QMP muet = QEMU figé ; scope absent + QMP muet = VM disparue. - `local_iface` n'est pas vérifié : interface préexistante que le subnet n'a pas créée. - Défaut `enabled: false` mais `true` dans `config.exemple.yml` : un host qui monte de version ne change pas de comportement, un déploiement neuf a le watchdog actif. **Durcissement au passage** — `pkg/systemd.Status` faisait trois assertions `props[...].(string)` **sans `, ok`**. Le watchdog interroge des noms d'unit arbitraires à chaque tick depuis une goroutine : une propriété manquante aurait paniqué et tué l'agent. **Risque tracé, décision de ne rien changer** — `pkg/systemd.New()` utilise `context.Background()` **sans timeout**, alors que le même fichier borne `Status` (5 s) et `job` (30 s). Si le socket D-Bus accepte sans répondre, le tick ne rend jamais la main et **le watchdog meurt en silence** — le pire mode de défaillance pour un composant de surveillance. Concerne aussi quatre appelants existants : `subnet/create.go`, `subnet/delete.go` et `metadata/handle.go` (deux fois), où une création de subnet ou un démarrage de VM peut se figer. Correctif si on y revient : `context.WithTimeout` dans `New()`, ou un `NewContext(ctx)` réservé au watchdog. **Reste à couvrir sous Linux** — tout le chemin après `netns.Exist() == true` : `checkSubnetNetns` 33 %, `checkVPC` 47 %, `checkVMTap` 69 %, `linkProblem` 60 %, `units` 60 %. Le cas « QMP répond » est testable sur macOS avec un faux serveur sur socket Unix.
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
syonad/two#29
No description provided.