La PriorityClass vault-critical de #46 é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.
La conséquence, qui n'est pas évidente
ArgoCD ne refuse pas seulement la ressource fautive : 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 ne sont pas arrivées non plus.
Ce qui rendait le diagnostic trompeur : prometheus, lui, a synchronisé sans problème. L'alerte VaultIndisponible de #46est en place dans la ConfigMap. La moitié du travail était visible, l'autre silencieusement bloquée.
Le changement : une ligne, un kind
- group:'scheduling.k8s.io'kind:PriorityClass
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 juste à côté — c'est ce que fait le commentaire ajouté.
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 accordé ici.
Vérifications
helm lint passe
helm template rend bien la nouvelle entrée
La liste compte cinq kinds au lieu de quatre
hashicorp-vault repasse Synced et la PriorityClass existe — à vérifier après merge
Une fois l'app synchronisée, les requests et le priorityClassName ne s'appliqueront au pod qu'à sa suppression (updateStrategy: OnDelete) — ce qui rescellera Vault. À faire au moment choisi, clé sous la main.
Suite de #46, et correctif de ma propre omission.
## Le symptôme
La `PriorityClass vault-critical` de #46 é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.
## La conséquence, qui n'est pas évidente
ArgoCD ne refuse pas seulement la ressource fautive : **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 ne sont **pas** arrivées non plus.
Ce qui rendait le diagnostic trompeur : `prometheus`, lui, a synchronisé sans problème. L'alerte `VaultIndisponible` de #46 **est** en place dans la ConfigMap. La moitié du travail était visible, l'autre silencieusement bloquée.
## Le changement : une ligne, un kind
```yaml
- group: 'scheduling.k8s.io'
kind: PriorityClass
```
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 juste à côté — c'est ce que fait le commentaire ajouté.
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 accordé ici.
## Vérifications
- [x] `helm lint` passe
- [x] `helm template` rend bien la nouvelle entrée
- [x] La liste compte cinq kinds au lieu de quatre
- [ ] `hashicorp-vault` repasse `Synced` et la PriorityClass existe — à vérifier après merge
## ⚠ Rappel de #46
Une fois l'app synchronisée, les `requests` et le `priorityClassName` ne s'appliqueront au pod qu'à sa **suppression** (`updateStrategy: OnDelete`) — ce qui **rescellera Vault**. À faire au moment choisi, clé sous la main.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
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]>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Suite de #46, et correctif de ma propre omission.
Le symptôme
La
PriorityClass vault-criticalde #46 était correcte, mais elle n'a jamais atteint le cluster :Une PriorityClass est cluster-scoped, et le
clusterResourceWhitelistde l'AppProjecttoolsne l'autorisait pas.La conséquence, qui n'est pas évidente
ArgoCD ne refuse pas seulement la ressource fautive : il fait échouer la synchronisation entière de l'application.
hashicorp-vaultest donc restéOutOfSyncaprès cinq tentatives — et lesrequestsmémoire de #46 ne sont pas arrivées non plus.Ce qui rendait le diagnostic trompeur :
prometheus, lui, a synchronisé sans problème. L'alerteVaultIndisponiblede #46 est en place dans la ConfigMap. La moitié du travail était visible, l'autre silencieusement bloquée.Le changement : une ligne, un kind
Cette liste est un garde-fou volontaire : elle borne ce qu'une application de
toolspeut créer hors de son namespace. On l'élargit donc d'un kind à la fois, avec sa raison écrite juste à côté — c'est ce que fait le commentaire ajouté.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 accordé ici.
Vérifications
helm lintpassehelm templaterend bien la nouvelle entréehashicorp-vaultrepasseSyncedet la PriorityClass existe — à vérifier après merge⚠ Rappel de #46
Une fois l'app synchronisée, les
requestset lepriorityClassNamene s'appliqueront au pod qu'à sa suppression (updateStrategy: OnDelete) — ce qui rescellera Vault. À faire au moment choisi, clé sous la main.🤖 Generated with Claude Code