-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Description
Is your feature request related to a problem? Please describe.
yes, it is related to a synchronization problem, when a vault-agent started it doesn't know about the vault service status (i.e. was it unsealed and initialized), in the same time it is trying to retrieve the data requested by a template no matter of the vault status, in the end transferring the vault-agent systemd service into the dormant state, and the only way to bring it back is to restart the vault-agent systemd service manually
related error
* permission denied (exceeded maximum retries)
comes from - https://github.com/hashicorp/consul-template/blob/master/watch/view.go#L164
Describe the solution you'd like
An additional flag to the vault-agent configuration to define a certain behavior to postpone any operations with the templates up until the vault status becomes unsealed and initialized
vault {
address = "https://127.0.0.1:8200"
wait_for_status = FLAG # true - to enabled, false - to disable this behavior
}Describe alternatives you've considered
there is wait flag available, it might help or might not, vault status might be undetermined after the wait interval ends
Explain any additional use-cases
potential use-case is to render templates with the vault agent on the consul instances of a vault ha cluster where the consul instances being used as storage backend (cyclic dependency)
Additional context
vault-agent being starting as systemd service