vault agent - respect consul-template retry configuration

[clatour]

The consul template retry stanza from configuration was not being passed
through appropriately, this should fix that.

Since a duration is not a valid HCL type, the swap from a simple hcl
decode had to be changed to mapstructure.

[hashicorp-cla]

All committers have signed the CLA.

[ncabatoff]

Hi @clatour,

Thanks for the PR!

I'm not too familiar with Agent's use of templating, but I suspect this may not fully address the original issue. A brief look at the code suggests that the consul-template lib's connection to Vault is managed independently of Agent's auto-auth code. So even if you make consul-template give up trying to talk to Vault via this config, Agent itself would still be spinning its wheels trying to talk to Vault. There's an incomplete PR (#8135) that tried to address that other bit.

Have you tested that this fix solves #6001 for you?

[clatour]

Hi @ncabatoff, on second glance, I think I may have linked the wrong issue. This patch does not alleviate the retry issue when the host is invalid or unreachable, only respects the retry configuration block for the vault agent configuration.

[avoidik]

hi @clatour there are two issues at the moment with retry-logic in vault agent:

1. an issue when the consul rendering server inside the vault agent service have failed to render templates and was terminated, but vault-agent service itself left in a half-working state (e.g. auto-auth works, rendering templates don't), and the only solution is to restart it vault agent - command execution over 30s disables template server completely #9108
2. vault not available due to sealed, not initialized, so vault agent pushes the maximum exceeded attempts also switching in to a half-working state where the only solution is to restart it Vault Agent: Add option to wait for sealed=false, intialized=true #8970

theoretically, this two are the events to trigger restart of vault-agent conditionally, but retry may help to resolve them unconditionally without any sophisticated logic implemented

[clatour]

Hi @avoidik,

I have edited my initial comment (and title) to remove the link to the outstanding vault agent retry issue. This is solely a patch to respect some configuration that is supported by consul template, and was documented as supported in vault-agent, but did not look to be wired through.

Currently the only instance in which I am using vault-agent is rendering templates as part of a deployment, where I’d like vault-agent to quickly set up, render template(s), and tear down. Similar to the idea of consul-templates once flag. So I’m not super familiar with any of the other retry mechanisms that exist when running vault-agent as a daemon.

What this solves for my use case is largely when a secret doesn’t exist or the template can’t otherwise be rendered, I’d like the consul-template component to allow itself to be configured to fail faster. Which I think is more related to your first point, but as-implemented would just cause the template rendering to be able to be shut down after a configurable retry, and not actually helping the retry/restart of that component overall.

[VioletHynes]

As this PR is older and cannot currently be merged due to merge conflicts, I’m going to go ahead and close it. Please feel free to open a new PR if your desired changes are still applicable!

However, additionally, I think there's a good chance the problem you're trying to solve was solved here: #16970