configure_vault is sometimes not called

[Mark Lopez]

There appears to be a race condition around configure_vault. In some cases (twice in a row for me) configure_vault is not called (or called in the incorrect order). This causes the systemd service to never be installed (and ultimately leaves the service blocked forever).

Removing and adding back the relationship with share-db invokes shared-db.available which forces a call to configure_vault.

[Liam Young (gnuoy)]

Thanks for the bug report. Please could you provide the juju log from the vault unit(s) ?

/var/log/juju/unit-vault*

The bundle you're using would also be very helpful.

Thanks
Liam

[Mark Lopez (silvenga)]

We were deploying charmed Kubernetes in high-availability mode.

Enclosed is an export of the bundle.

I've been looking for the logs in the backups, and I can't seem to find the relevant one's. I think they may be gone with the retention policies.

Vault was originally deployed as a single unit to bootstrap the cluster, then was scaled out to 3 units. This was a manual deployment (on SaltStack provisioned VM's).