Ajout d'un watchdog #29
Labels
No labels
bug fix
feature implementation
new feature
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
syonad/two#29
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
En gros il faut ajouter un system qui check l'etat des elements.
toujours en test
me reste quelque ellements a confirmer
je ne suis toujours pas sur que le denier commit sois valide
nop toujours pas et ca m'embete
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
runningest vérifié — ni les états transitoires nierror/deleted, pour éviter les faux positifs.Décision anti-flood — interface de notification nue, répétition assumée :
Notifyest 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
yaml:n'auraient rien bindé, le watchdog ne serait jamais parti, en silence. Tagsmapstructure:.<vpc>_<bridge>, soitdnsmasq@vp-admin_br-000000.service, et non<vpc>_<subnet>.subnetIDvient du nom du subnet, pas deTrimPrefix(local_iface, "br-")—local_ifaceest une interface distincte.Décisions de conception
vpcIfaceNamesne panique pas là oùvpc.CreateVPCle fait : le watchdog itère sur le contenu de la base, une panique dans sa goroutine tuerait tout l'agent.unitCheckeren interface : une seule connexion D-Bus par tick au lieu d'une par ressource, et la vérification d'unit devient testable hors Linux.dbusDown), sinon 1440 avertissements par jour.interval <= 0retombe sur 60 s :time.NewTickerpanique sur une durée nulle, uninterval_secondsoublié aurait empêché l'agent de démarrer.local_ifacen'est pas vérifié : interface préexistante que le subnet n'a pas créée.enabled: falsemaistruedansconfig.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.Statusfaisait trois assertionsprops[...].(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()utilisecontext.Background()sans timeout, alors que le même fichier borneStatus(5 s) etjob(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.goetmetadata/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.WithTimeoutdansNew(), ou unNewContext(ctx)réservé au watchdog.Reste à couvrir sous Linux — tout le chemin après
netns.Exist() == true:checkSubnetNetns33 %,checkVPC47 %,checkVMTap69 %,linkProblem60 %,units60 %. Le cas « QMP répond » est testable sur macOS avec un faux serveur sur socket Unix.