Comment 23 for bug 1871981

Revision history for this message
Zachary Zehring (zzehring) wrote :

I encountered this issue on 19.10 in an 3-unit HA Vault deployment. Checking the vault relation data that's provided to barbican-vault units, the non-leader vaults also are providing a token which are the old tokens from when the leader was different. To resolve, the following steps were taken (vault/1 is the leader):

1. refresh secrets using vault lead
juju run-action --wait vault/leader refresh-secrets

2. unset all but leader barbican-vault/X_token using relation-set
juju run -u vault/0,vault/2 -- relation-set -r secrets-storage:402 barbican-vault/0_token='' barbican-vault/1_token='' barbican-vault/2_token=''

3. juju resolve --no-retry on the units until they correctly have the tokens set (check what's currently set by using "relation-get -r secrets-storage - vault/1")

4. repeat until you get to the point where barbican-vault picks up the correct token
NOTE: when refreshing secrets, barbican-vault does not get the new token until resolve --no-retry is run, as it will try with the old token. Also, the tokens are only good for an hour, so the above must be done within an hour of refreshing secrets.