You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We run a somewhat unconventional consul/vault setup, in that our clusters are far away from some of our servers and thus latency is pretty poor. With the hard-coded inactivity_timeout for vault of 1s here
consul-templaterb often times out during a run for some keys. I confirmed that increasing this to a longer time fixes the issue. Potentially somewhat of a niche request, but making this configurable would allow increase the timeout in cases where vault was a stupid distance away from the host consul-templaterb was running on.
The text was updated successfully, but these errors were encountered:
@steveberryman Indeed, this is pretty hardcoded... there are lots of places where we borrow parameters from the command line, would you be interested with providing a patch?
On 20 Aug 2021, 16:25 +0100, Pierre Souchay ***@***.***>, wrote:
@steveberryman Indeed, this is pretty hardcoded... there are lots of places where we borrow parameters from the command line, would you be interested with providing a patch?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
We run a somewhat unconventional consul/vault setup, in that our clusters are far away from some of our servers and thus latency is pretty poor. With the hard-coded
inactivity_timeout
for vault of 1s hereconsul-templaterb/lib/consul/async/vault_endpoint.rb
Line 234 in fa13ad2
consul-templaterb often times out during a run for some keys. I confirmed that increasing this to a longer time fixes the issue. Potentially somewhat of a niche request, but making this configurable would allow increase the timeout in cases where vault was a stupid distance away from the host consul-templaterb was running on.
The text was updated successfully, but these errors were encountered: