La PriorityClass de Vault était refusée par l'AppProject, et toute l'app restait OutOfSync #47

Merged

arcodange merged 1 commits from arcodange/vault-priorityclass into main 2026-09-11 15:27:31 +02:00

Conversation 0 Commits 1 Files Changed 1

+16 -1

1 Commits

Author	SHA1	Message	Date
arcodangeandClaude Opus 5	3cfa83b2d6	La PriorityClass de Vault était refusée par l'AppProject, et toute l'app restait OutOfSync ... Suite de #46. La PriorityClass `vault-critical` y était correcte, mais elle n'a jamais atteint le cluster : SyncFailed | PriorityClass/vault-critical resource scheduling.k8s.io:PriorityClass is not permitted in project tools Une PriorityClass est cluster-scoped, et le `clusterResourceWhitelist` de l'AppProject `tools` ne l'autorisait pas. Conséquence non évidente : ArgoCD ne refuse pas seulement cette ressource, il fait échouer la SYNCHRONISATION ENTIÈRE de l'application. `hashicorp-vault` est donc resté OutOfSync après cinq tentatives, et les `requests` mémoire de #46 n'ont pas atterri non plus. À côté, `prometheus` a synchronisé sans problème : l'alerte VaultIndisponible de #46 est bien en place dans la ConfigMap. C'est ce qui rendait le symptôme trompeur — la moitié du travail était visible. CE QUE CE CHANGEMENT FAIT, ET CE QU'IL NE FAIT PAS Une ligne, un kind. Cette liste est un garde-fou volontaire : elle borne ce qu'une application de `tools` peut créer hors de son namespace. On l'élargit donc d'un kind à la fois, avec sa raison écrite à côté. Une PriorityClass ne porte ni droit ni donnée. Elle ne fait qu'ordonner l'éviction et la préemption — c'est le seul pouvoir qu'on accorde ici. Vérifié : `helm lint` passe, `helm template` rend bien l'entrée, et la liste compte désormais cinq kinds au lieu de quatre. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-11 15:25:00 +02:00