nonobis/Heimdall
Watch
1
0
Fork
You've already forked Heimdall
 0
Code Issues 24 Pull requests Projects Releases Packages Activity Actions 1

FEAT: Broker de jobs d'analyse — RabbitMQ + MassTransit (mutualisation IA/GPU inter-sites) #72

New issue
Closed
opened 2026-08-12 09:46:39 +02:00 by nonobis · 0 comments
nonobis commented 2026-08-12 09:46:39 +02:00
Owner
Copy link

🎯 Contexte

Objectif produit : mutualiser les ressources IA/GPU entre sites. Un site sans GPU doit pouvoir déléguer l'analyse de ses frames à des agents équipés GPU, même sur un autre site physique. Ce broker est le socle, extensible à toute opération déléguable (YOLO, OCR plaque, encodage clip, agrégation).

Décision d'architecture (vérifiée — fiche KB-HEIMDALL-ORLEANS du 12/08/2026) : Microsoft.Orleans est écarté — non-goal déclaré par les mainteneurs (pas de connexion directe de tiers au cluster ; TCP direct entre silos requis ; détection de panne WAN inadaptée : un silo déclaré mort se tue lui-même ; multi-clustering retiré depuis v2 et epic #7485 non livré depuis 2022). Les agents Heimdall sont derrière des NAT différents → le pattern passerelle actuel (HTTPS heartbeat) est le bon, et la mutualisation passe par une file de jobs durable : RabbitMQ + MassTransit (solution B retenue). Les agents restent producteurs/consommateurs en sortie NAT (connexion AMQP sortante vers le broker central), aucun port entrant à ouvrir.

🔍 État actuel (vérifié dans le code)

Analyse 100 % locale aujourd'hui : l'agent capture (CameraStreamService → SnapshotPipelineService) et appelle FrameAnalyzerService.AnalyzeFrameAsync (stub RunInference → [], pas encore d'inférence réelle — cf. ticket #2). Le central orchestre l'assignation caméras→agents via Hangfire (heartbeat-monitor, agent-failover /1 min) et pousse la config par pull HTTPS (ConfigReceiverService). Aucune file de messages dans le stack (aucun conteneur RabbitMQ, aucun package MassTransit).

🧩 À faire

  • Ajouter le conteneur rabbitmq:3-management au docker-compose (dev + prod) : user/vhost dédiés Heimdall, credentials via secrets/env, port management exposé au central uniquement
  • Ajouter les packages MassTransit + MassTransit.RabbitMQ au projet Web (central) et au projet Agent
  • Définir les contrats de messages partagés (nouveau projet Heimdall.Contracts ou dossier commun) : AnalysisJobRequested, AnalysisJobCompleted, AnalysisJobFailed, AnalysisJobCancelled (+ enveloppe : JobId, SiteId, CameraId, OperationType, Priority, PayloadRef, Timestamps)
  • Configurer le bus : endpoint RabbitMQ central, retry policy (ex. 3 tentatives avec backoff), dead-letter exchange, prefetch count
  • Abstraire derrière IAnalysisJobQueue (publish/subscribe) pour testabilité — l'implémentation RabbitMQ/MassTransit est derrière l'interface
  • Côté central : consommer les résultats (AnalysisJobCompleted) et les relier aux événements caméra existants (reporting détections)
  • Côté agent : config du broker (URL, credentials) via les settings distants (ConfigReceiverService) avec fallback local
  • Health check broker (connexion AMQP, file vide/accumulation) + métriques OpenTelemetry (jobs publiés/consommés/échoués, latence)
  • Tests : publication/consommation (Testcontainers RabbitMQ ou transport in-memory MassTransit), retry, dead-letter

🧪 Critères d'acceptation

  • Un job soumis par l'agent capteur (site A) est consommé et exécuté par l'agent GPU (site B) — sites différents
  • Un échec d'exécution déclenche le retry puis le dead-letter après N tentatives (job visible en DLQ, pas perdu)
  • Aucun port entrant requis côté agent (connexion sortante uniquement)
  • Le broker redémarre sans perte de jobs en vol (durabilité des files)
  • make test vert

📁 Fichiers concernés

docker/docker-compose.yml, docker/docker-compose.prod.yml, src/Heimdall.Contracts/ (nouveau), src/Heimdall.Web/Program.cs, src/Heimdall.Web/appsettings.json, src/Heimdall.Agent/Program.cs, src/Heimdall.Infrastructure/ (config bus + services), tests/

⚠️ Impact

Ajoute un point d'infrastructure central (RabbitMQ) — à sécuriser (credentials), sauvegarder et surveiller. Risque de régression faible : l'existant (Hangfire, SignalR, heartbeat) reste inchangé tant que les agents ne basculent pas en mode remote.

📝 Notes

Dépend de : ticket #2 (inférence réelle) pour que les jobs produisent des détections ; tickets capacités GPU + ordonnanceur pour le routage ; ticket docker GPU pour que les consommateurs aient accès au matériel. Fiche de recherche : ~/.hermes/profiles/the-librarian/cache/fiches/KB-HEIMDALL-ORLEANS/.

## 🎯 Contexte **Objectif produit : mutualiser les ressources IA/GPU entre sites.** Un site sans GPU doit pouvoir déléguer l'analyse de ses frames à des agents équipés GPU, même sur un autre site physique. Ce broker est le socle, extensible à toute opération déléguable (YOLO, OCR plaque, encodage clip, agrégation). **Décision d'architecture (vérifiée — fiche KB-HEIMDALL-ORLEANS du 12/08/2026) :** Microsoft.Orleans est **écarté** — non-goal déclaré par les mainteneurs (pas de connexion directe de tiers au cluster ; TCP direct entre silos requis ; détection de panne WAN inadaptée : un silo déclaré mort se tue lui-même ; multi-clustering retiré depuis v2 et epic #7485 non livré depuis 2022). Les agents Heimdall sont derrière des NAT différents → le pattern passerelle actuel (HTTPS heartbeat) est le bon, et la mutualisation passe par une **file de jobs durable** : **RabbitMQ + MassTransit (solution B retenue)**. Les agents restent producteurs/consommateurs en sortie NAT (connexion AMQP sortante vers le broker central), aucun port entrant à ouvrir. ## 🔍 État actuel (vérifié dans le code) Analyse **100 % locale** aujourd'hui : l'agent capture (CameraStreamService → SnapshotPipelineService) et appelle `FrameAnalyzerService.AnalyzeFrameAsync` (stub `RunInference` → `[]`, pas encore d'inférence réelle — cf. ticket #2). Le central orchestre l'assignation caméras→agents via Hangfire (`heartbeat-monitor`, `agent-failover` /1 min) et pousse la config par pull HTTPS (`ConfigReceiverService`). **Aucune file de messages dans le stack** (aucun conteneur RabbitMQ, aucun package MassTransit). ## 🧩 À faire - [ ] Ajouter le conteneur `rabbitmq:3-management` au docker-compose (dev + prod) : user/vhost dédiés Heimdall, credentials via secrets/env, port management exposé au central uniquement - [ ] Ajouter les packages `MassTransit` + `MassTransit.RabbitMQ` au projet Web (central) et au projet Agent - [ ] Définir les **contrats de messages partagés** (nouveau projet `Heimdall.Contracts` ou dossier commun) : `AnalysisJobRequested`, `AnalysisJobCompleted`, `AnalysisJobFailed`, `AnalysisJobCancelled` (+ enveloppe : JobId, SiteId, CameraId, OperationType, Priority, PayloadRef, Timestamps) - [ ] Configurer le bus : endpoint RabbitMQ central, retry policy (ex. 3 tentatives avec backoff), dead-letter exchange, prefetch count - [ ] Abstraire derrière `IAnalysisJobQueue` (publish/subscribe) pour testabilité — l'implémentation RabbitMQ/MassTransit est derrière l'interface - [ ] Côté central : consommer les résultats (`AnalysisJobCompleted`) et les relier aux événements caméra existants (reporting détections) - [ ] Côté agent : config du broker (URL, credentials) via les settings distants (`ConfigReceiverService`) avec fallback local - [ ] Health check broker (connexion AMQP, file vide/accumulation) + métriques OpenTelemetry (jobs publiés/consommés/échoués, latence) - [ ] Tests : publication/consommation (Testcontainers RabbitMQ ou transport in-memory MassTransit), retry, dead-letter ## 🧪 Critères d'acceptation - [ ] Un job soumis par l'agent capteur (site A) est consommé et exécuté par l'agent GPU (site B) — **sites différents** - [ ] Un échec d'exécution déclenche le retry puis le dead-letter après N tentatives (job visible en DLQ, pas perdu) - [ ] Aucun port entrant requis côté agent (connexion sortante uniquement) - [ ] Le broker redémarre sans perte de jobs en vol (durabilité des files) - [ ] `make test` vert ## 📁 Fichiers concernés docker/docker-compose.yml, docker/docker-compose.prod.yml, src/Heimdall.Contracts/ (nouveau), src/Heimdall.Web/Program.cs, src/Heimdall.Web/appsettings.json, src/Heimdall.Agent/Program.cs, src/Heimdall.Infrastructure/ (config bus + services), tests/ ## ⚠️ Impact Ajoute un point d'infrastructure central (RabbitMQ) — à sécuriser (credentials), sauvegarder et surveiller. Risque de régression faible : l'existant (Hangfire, SignalR, heartbeat) reste inchangé tant que les agents ne basculent pas en mode remote. ## 📝 Notes Dépend de : ticket #2 (inférence réelle) pour que les jobs produisent des détections ; tickets capacités GPU + ordonnanceur pour le routage ; ticket docker GPU pour que les consommateurs aient accès au matériel. Fiche de recherche : `~/.hermes/profiles/the-librarian/cache/fiches/KB-HEIMDALL-ORLEANS/`.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feat/migrate-ci-woodpecker
feat/implement-all-5-tickets-complètement
fix/pending-model-changes-warning
feat/131-user-camera-access-entity
feat/11-persons-ui
feat/mobile-feature
feat/134-camera-access-panel-ui
feat/89-confirm-user-email
fix/27-e2e-tests
feat/133-user-camera-access-api
feat/141-camera-access-tests
fix/mobile-ci
feat/110-camera-discovery-ui
feat/136-filter-sites-by-user-access
feat/142-i18n-localization
feat/14-opentelemetry-metrics
feat/59-toggle-camera-status
feat/75-agent-remote-mode
feat/76-agent-gpu-worker
feat/86-agent-inventory-ui
fix/25-readme-update
fix/47-auth-redirect
fix/77-docker-compose-gpu
feat/11-persons-ui-new
feat/88-edit-user-email
fix/ci-infra-heimdall
feat/feat-application-mobile-android-kotlin-jetpack-com
feat/feat-release-notes-automatiques-forgejo-changelog
feat/feat-service-icameraaccessservice-r-solution-des-a
feat/feat-backup-automatis-postgresql-alarik-avec-test-
feat/feat-filtrage-cam-ras-adapter-getcamerasbysite-aux
feat/feat-suppression-de-site-en-cascade-agents-et-cam-
feature/auto-update-docker
feature/auto-update-native
feature/audit-full-coverage
feat/agent-inventory-ui
feat/integration-settings-ui
feat/ntfy-config-complete
feat/agent-gpu-consumer
fix/ci-refonte-politique-143
No results found.
Labels
Clear labels   
bug
Comportement incorrect ou risque fonctionnel

  
chore
Maintenance, dépendances, CI, outillage

  
design
Ticket avec composante UI — maquette the-designer requise/intégrée

  
dx:ci

   
dx:database

   
dx:dotnet

   
dx:infra

   
dx:security

   
dx:tests

   
dx:ui

   
etape-1
Étape 1 — MVP Multi-Site (phases 1-12)

  
etape-2
Étape 2 — Caméras + Temps réel (phases 13-14)

  
etape-3
Étape 3 — Vidéo + IA (phases 15-16)

  
etape-4
Étape 4 — Événements + Notifications (phases 17-19)

  
etape-5
Étape 5 — UI Blazor complète (phases 20-23)

  
etape-6
Étape 6 — Production Hardening (phase 24)

  
etape-7
Étape 7 — Mobile (phase 25)

  
feature
Nouvelle fonctionnalité / implémentation spec manquante

  
priority-high
Priorité haute — bloque le cœur métier

  
priority-low
Priorité faible / cosmétique

  
priority-medium
Priorité moyenne

  
security
Vulnérabilités CVE, scans Trivy/OWASP, security hardening

  
spec
Référence à MASTER_SPECIFICATION.md

  
tech-debt
Dette technique, obsolescence, drift documentation

No labels
bug
chore
design
dx:ci
dx:database
dx:dotnet
dx:infra
dx:security
dx:tests
dx:ui
etape-1
etape-2
etape-3
etape-4
etape-5
etape-6
etape-7
feature
priority-high
priority-low
priority-medium
security
spec
tech-debt
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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
nonobis/Heimdall#72
No description provided.