vault-charm

configure_vault is sometimes not called

Bug #1809636 reported by Mark Lopez
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
vault-charm
Incomplete
Undecided
Unassigned

Bug Description

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.

Revision history for this message
Liam Young (gnuoy) wrote :

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

Changed in vault-charm:
status: New → Incomplete
Revision history for this message
Mark Lopez (silvenga) wrote :

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).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.