Description
Le problème
Sur une installation où ArgoCD infra tourne sur le même cluster que le socle cible (single-cluster,
pas l'archi 2-clusters de référence), le premier run d'install-gitops.yaml peut écrire une valeur
vide pour vault_infra_token dans Vault, à cause d'un problème de timing : Vault infra vient
juste d'être unsealed dans ce même run, donc le token n'est pas toujours disponible au moment où
on va le lire.
Le vrai souci, c'est qu'une fois cette valeur écrite vide, plus aucun re-run du playbook ne la
corrige, même quand le token est correctement récupéré sur les runs suivants. J'ai vérifié avec
-vvv : le token correct est bien calculé, mais il est silencieusement jeté à cause du merge dans
roles/gitops/vault-secrets/tasks/write.yml (ligne 43) :
cmd: |
echo '{ "old": {{ current_vault_values.secret | ... }}, "new": {{ item.1.vault_values | ... }} }' \
| yq -p=json -o=json -I=0 '.old *n .new'
Le flag n de yq fait que si une clé existe déjà côté old (même avec une valeur vide ""), elle
n'est jamais remplacée par la nouvelle valeur côté new.
Est ce que c'est voulu comme mécanisme ?? Ou bien c'est vraiment spécifique à l'architecture single cluster ?
Preuve (log -vvv)
Tâche Get current non null values, app global :
"old": {"vault_infra_token": "", ...}
"new": {"vault_infra_token": "hvs.XXXXXX", ...}
Résultat après le merge yq '.old *n .new' :
{"vault_infra_token": "", ...}
Le vrai token est jeté, la valeur vide reste. Du coup Compare vault values ne voit aucun
changement et Update vault secret est skip — rien n'est jamais écrit.
Conséquence
vault_infra_token sert à authentifier les Jobs post-install in-cluster (cpn-ansible-job pour
Keycloak, GitLab, Harbor, etc.) auprès de Vault. Avec un token vide, ces Jobs échouent avec
403 Forbidden, et toute la post-installation applicative reste bloquée (client OIDC Keycloak
jamais créé, secret oidcProvider de GitLab jamais rempli, pods GitLab bloqués en Init...) sans
qu'aucun re-run ne puisse s'auto-réparer.
Suggestion
yq -p=json -o=json -I=0 '(.old | del(.vault_infra_token)) as $old | $old *n .new'
en supprimant juste vault_infra_token de old, on le traite comme une clé "jamais renseignée" à chaque run → toujours rafraîchi avec la vraie valeur.
Contexte
- Architecture : cluster unique, ArgoCD infra auto-hébergé sur le même cluster que la cible.
- Version socle : 4.9.2
Etapes de reproduction
1. Aller à '...'
2. Cliquer sur '....'
3. Scroller jusqu'à '....'
4. Voir l'erreur
Captures d'écran
Logs
No response
Navigateurs
No response
OS
No response
Version de la console impactée
No response
Définition du fini
Description
Le problème
Sur une installation où ArgoCD infra tourne sur le même cluster que le socle cible (single-cluster,
pas l'archi 2-clusters de référence), le premier run d'
install-gitops.yamlpeut écrire une valeurvide pour
vault_infra_tokendans Vault, à cause d'un problème de timing : Vault infra vientjuste d'être unsealed dans ce même run, donc le token n'est pas toujours disponible au moment où
on va le lire.
Le vrai souci, c'est qu'une fois cette valeur écrite vide, plus aucun re-run du playbook ne la
corrige, même quand le token est correctement récupéré sur les runs suivants. J'ai vérifié avec
-vvv: le token correct est bien calculé, mais il est silencieusement jeté à cause du merge dansroles/gitops/vault-secrets/tasks/write.yml(ligne 43) :Le flag
nde yq fait que si une clé existe déjà côtéold(même avec une valeur vide""), ellen'est jamais remplacée par la nouvelle valeur côté
new.Est ce que c'est voulu comme mécanisme ?? Ou bien c'est vraiment spécifique à l'architecture single cluster ?
Preuve (log
-vvv)Tâche
Get current non null values, appglobal:Résultat après le merge
yq '.old *n .new':Le vrai token est jeté, la valeur vide reste. Du coup
Compare vault valuesne voit aucunchangement et
Update vault secretest skip — rien n'est jamais écrit.Conséquence
vault_infra_tokensert à authentifier les Jobs post-install in-cluster (cpn-ansible-jobpourKeycloak, GitLab, Harbor, etc.) auprès de Vault. Avec un token vide, ces Jobs échouent avec
403 Forbidden, et toute la post-installation applicative reste bloquée (client OIDC Keycloakjamais créé, secret
oidcProviderde GitLab jamais rempli, pods GitLab bloqués enInit...) sansqu'aucun re-run ne puisse s'auto-réparer.
Suggestion
en supprimant juste vault_infra_token de old, on le traite comme une clé "jamais renseignée" à chaque run → toujours rafraîchi avec la vraie valeur.
Contexte
Etapes de reproduction
Captures d'écran
Logs
No response
Navigateurs
No response
OS
No response
Version de la console impactée
No response
Définition du fini