consul-template: Add fault tolerant defaults

client/config/config.go

@@ -64,7 +64,7 @@ var (
 		"/run/systemd/resolve": "/run/systemd/resolve",
 	}
 
-	DefaultTemplateMaxStale = 5 * time.Second
+	DefaultTemplateMaxStale = 87600 * time.Hour
 
 	DefaultTemplateFunctionDenylist = []string{"plugin", "writeToFile"}
 )
@@ -717,8 +717,24 @@ func DefaultConfig() *Config {
 		NoHostUUID:              true,
 		DisableRemoteExec:       false,
 		TemplateConfig: &ClientTemplateConfig{
-			FunctionDenylist: DefaultTemplateFunctionDenylist,
-			DisableSandbox:   false,
+			FunctionDenylist:   DefaultTemplateFunctionDenylist,
+			DisableSandbox:     false,
+			BlockQueryWaitTime: helper.TimeToPtr(5 * time.Minute),         // match Consul default
+			MaxStale:           helper.TimeToPtr(DefaultTemplateMaxStale), // match Consul default
+			Wait: &WaitConfig{
+				Min: helper.TimeToPtr(5 * time.Second),
+				Max: helper.TimeToPtr(4 * time.Minute),
+			},
+			ConsulRetry: &RetryConfig{
+				Attempts:   helper.IntToPtr(0), // unlimited
+				Backoff:    helper.TimeToPtr(250 * time.Millisecond),
+				MaxBackoff: helper.TimeToPtr(1 * time.Minute),
+			},
+			VaultRetry: &RetryConfig{
+				Attempts:   helper.IntToPtr(0), // unlimited
+				Backoff:    helper.TimeToPtr(250 * time.Millisecond),
+				MaxBackoff: helper.TimeToPtr(1 * time.Minute),
+			},
 		},
 		RPCHoldTimeout:     5 * time.Second,
 		CNIPath:            "/opt/cni/bin",

website/content/docs/configuration/client.mdx

@@ -217,14 +217,14 @@ chroot as doing so would cause infinite recursion.
   files on the client host via the `file` function. By default, templates can
   access files only within the [task working directory].
 
-- `max_stale` `(string: "")` - # This is the maximum interval to allow "stale"
+- `max_stale` `(string: "87600h")` - # This is the maximum interval to allow "stale"
   data. By default, only the Consul leader will respond to queries. Requests to
   a follower will forward to the leader. In large clusters with many requests,
   this is not as scalable. This option allows any follower to respond to a query,
   so long as the last-replicated data is within this bound. Higher values result
   in less cluster load, but are more likely to have outdated data.
 
-- `wait` `(Code: nil)` - Defines the minimum and maximum amount of time to wait
+- `wait` `(Code: { min = "5s" max = "4m" })` - Defines the minimum and maximum amount of time to wait
   for the Consul cluster to reach a consistent state before rendering a template.
   This is useful to enable in systems where network connectivity to Consul is degraded,
   because it will reduce the number of times a template is rendered. This configuration is
@@ -233,7 +233,7 @@ chroot as doing so would cause infinite recursion.
   ```hcl
   wait {
     min     = "5s"
-    max     = "10s"
+    max     = "4m"
   }
   ```
 
@@ -250,23 +250,23 @@ chroot as doing so would cause infinite recursion.
   }
     ```
 
-- `block_query_wait` `(string: "60s")` - This is amount of time in seconds to wait
+- `block_query_wait` `(string: "5m")` - This is amount of time in seconds to wait
   for the results of a blocking query. Many endpoints in Consul support a feature known as
   "blocking queries". A blocking query is used to wait for a potential change
   using long polling.
 
-- `consul_retry` `(Code: nil)` - This controls the retry behavior when an error is
-  returned from Consul. Consul Template is highly fault tolerant, meaning it does
-  not exit in the face of failure. Instead, it uses exponential back-off and retry
-  functions to wait for the cluster to become available, as is customary in distributed
-  systems.
+- `consul_retry` `(Code: { attempts = 0 backoff = "250ms" max_backoff = "1m" })`-
+  This controls the retry behavior when an error is returned from Consul. Consul
+  Template is highly fault tolerant, meaning it does not exit in the face of failure.
+  Instead, it uses exponential back-off and retry functions to wait for the cluster
+  to become available, as is customary in distributed systems.
 
   ```hcl
   consul_retry {
     # This specifies the number of attempts to make before giving up. Each
     # attempt adds the exponential backoff sleep time. Setting this to
     # zero will implement an unlimited number of retries.
-    attempts = 12
+    attempts = 0
     # This is the base amount of time to sleep between retry attempts. Each
     # retry sleeps for an exponent of 2 longer than this base. For 5 retries,
     # the sleep times would be: 250ms, 500ms, 1s, 2s, then 4s.
@@ -280,18 +280,18 @@ chroot as doing so would cause infinite recursion.
   }
   ```
 
-- `vault_retry` `(Code: nil)` - This controls the retry behavior when an error is
-  returned from Vault. Consul Template is highly fault tolerant, meaning it does
-  not exit in the face of failure. Instead, it uses exponential back-off and retry
-  functions to wait for the cluster to become available, as is customary in distributed
-  systems.
+- `vault_retry` `(Code: { attempts = 0 backoff = "250ms" max_backoff = "1m" })` -
+  This controls the retry behavior when an error is returned from Vault. Consul
+  Template is highly fault tolerant, meaning it does not exit in the face of failure.
+  Instead, it uses exponential back-off and retry functions to wait for the cluster
+  to become available, as is customary in distributed systems.
 
   ```hcl
   vault_retry {
     # This specifies the number of attempts to make before giving up. Each
     # attempt adds the exponential backoff sleep time. Setting this to
     # zero will implement an unlimited number of retries.
-    attempts = 12
+    attempts = 0
     # This is the base amount of time to sleep between retry attempts. Each
     # retry sleeps for an exponent of 2 longer than this base. For 5 retries,
     # the sleep times would be: 250ms, 500ms, 1s, 2s, then 4s.