refactor(cluster): migrate module from server

[shikanime]

Issues liées

Refs #2492

---

Quel est le comportement actuel ?

Le module cluster (clusters, usage, environnements) est servi par l'ancienne application Fastify apps/server.

Quel est le nouveau comportement ?

Migration du module cluster vers apps/server-nestjs :

• ClusterController : routes GET /, GET /:clusterId, GET /usage/:clusterId, GET /:clusterId/environments, POST /, PUT /:clusterId, DELETE /:clusterId.
• ClusterService : CRUD + calcul d'usage et liste des environnements rattachés.
• ClusterModule : enregistrement dans main.module.ts.
• Parité des contrats et codes HTTP contre apps/server/src/resources/cluster/.

État lors de la bascule

Cette PR migre le module côté server-nestjs mais ne bascule pas encore le trafic : le routage reste porté par l'ancienne application, ce qui rend le point de routage non bloquant ici mais à traiter dans la vague de bascule.

• Routage : apps/nginx-strangler/conf.d/routing.conf ne contient aucune location /api/v1/clusters sur cette branche ; /api/v1/clusters retombe donc dans location /api/ → server-legacy. Les routes migrées ne sont pas encore servies par server-nestjs.
• Hooks : ClusterService émet cluster.upsert / cluster.delete via EventEmitter2, et server-nestjs porte les listeners correspondants (argocd.service.ts : @OnEvent('cluster.upsert') → syncCluster, @OnEvent('cluster.delete') → cleanupCluster, résultats argocd centralisés via capturePluginResult) ; l'écouteur historique reste dans l'ancienne application (apps/server/src/utils/hook-wrapper.ts, câblé par apps/server/src/resources/cluster/business.ts). À la bascule du routage, l'émission côté server-nestjs déclenchera donc le provisionnement — aucun risque de no-op ; la vague de bascule n'a plus que le bloc location /api/v1/clusters à porter.

Cette PR introduit-elle un breaking change ?

Non.

Autres informations

[shikanime]

Réouverte : couverture des familles restantes pour #1889 — le fermeture précédente était un tri, pas un rejet du travail.

[shikanime]

Réouverte : famille requise pour #1889. Branche recréée depuis le SHA d'origine (l'ancienne ref avait été supprimée).

[shikanime]

🔴 Bloquant pour la bascule : emitAsync('cluster.upsert'/'cluster.delete') n'a aucun consommateur @OnEvent dans server-nestjs. Les abonnés legacy du hook cluster sont argocd, gitlab et vault — le pont reste à écrire (même pattern que #2749 pour adminRole.*). Rien de cassé tant qu'apps/server sert la route.

[shikanime]

Revue de conformité menée contre la base de code et le vocabulaire des conventions (cpn) : couche requêtes (sélectifs *Select sous satisfies Prisma.*Select, verbes list*/get*/upsert* Prisma-only, generateClusterWhereInput), pipeline d'événements (échec plugin → 422 centralisé dans AppEventsService.throwOnPluginFailure, hook avant mutation pour que la suppression reste rejouable) et specs de matrice de permissions suivent les conventions du dépôt. Un point de parité bloquant : la forme du secret ArgoCD déplace username/password/bearerToken hors du bloc tlsClientConfig par rapport au legacy (convertConfig dans plugins/argocd/src/cluster.ts), ce qui casserait l'authentification par token/login des clusters à la bascule ; trois points importants l'accompagnent (erreur brute dans le bridge argocd au lieu d'un KO plugin, message 422 création/mise à jour replié sur une seule formulation, mutation du body typé dans updateCluster). Pas d'approbation : retour au porteur après correction.

[shikanime]

Revue du head 17a9b3b0 (rebase + restauration des throws locaux par le pattern zone). Le module cluster est propre : union EventLogAction bien complétée avec 'Create Cluster' | 'Update Cluster' | 'Delete Cluster', wrapper emitClusterEventAndThrowOnFailure qui reproduit le 422 legacy (le delete n'est émis qu'après nettoyage plugins, la ligne ne disparaît qu'après OK de tous les plugins), listeners @OnEvent('cluster.upsert') / @OnEvent('cluster.delete') portés dans argocd.service.ts (contrairement à ce qu'affirme encore le corps de la PR), aucun cast as, pas de specs supprimées, imports de module minimaux. Les interactions Vault ajoutées (upsertKvData / deleteKvMetadata pour le secret cluster ArgoCD) sont idempotentes et tolèrent le 404 à la suppression — conformes au pattern existant. Rien de bloquant.

Résumé des sévérités : 0 bloquant, 1 important, 1 nit.

[shikanime]

important — Le corps de la PR (section « État lors de la bascule ») affirme encore que « server-nestjs n'a aucun @onevent('cluster.upsert') ni @onevent('cluster.delete') » et que l'émission sera un no-op à la bascule. C'est faux sur ce head : les listeners existent dans argocd.service.ts (lignes 73 et 100). Mettre à jour le corps — c'est la note qui décide si #2756 peut fusionner sans risque de no-op. Profiter pour corriger la route listée GET /:clusterId/usage → le contrat est /usage/:clusterId.

[shikanime]

Le corps de la PR a été corrigé entre-temps : la section « État lors de la bascule » documente désormais les listeners @OnEvent('cluster.upsert'/'cluster.delete') d'argocd.service.ts et conclut à l'absence de no-op. Marqué à jour.

[shikanime]

nit — Le legacy distingue deux messages : « Echec des services à la création du cluster » (business.ts:132) et « Echec des services à la mise à jour du cluster » (business.ts:198). Ici create et update partagent « à la création/mise à jour ». Parité stricte des messages d'erreur = un message par appel ; deux chaînes distinctes coûtent zéro ligne de plus.

[shikanime]

Corrigé dans 8655a0f : messages séparés aux libellés legacy exacts (« …à la création du cluster » / « …à la mise à jour du cluster »).

[cloud-pi-native-sonarqube]

Quality Gate passed

Issues

• 1 New Issue
• 0 Fixed Issues
• 0 Accepted Issues

Measures

• 0 Security Hotspots
• 1.90% Coverage (23.20% Estimated after merge)
• 0.00% Duplicated Code (3.70% Estimated after merge)

Project ID: cloud-pi-native_console_AYsa46O31ebDtzs-pYyZ

View in SonarQube