Templates continually rendered when using global wait and multiple templates

[alexcreek]

I'm not sure if this is a bug or a feature. I get different results when using different wait times and number of templates. Clarity on the expected behavior would help clear this up.

Consul Template version

consul-template v0.20.0 (b709612c)

Configuration

/etc/consul-template.hcl
consul {
  address = "127.0.0.1:8500"
  retry {
    enabled = true
    attempts = 12
    backoff = "250ms"
    max_backoff = "1m"
  }
}
log_level = "trace"
pid_file = "/var/run/consul-template.pid"
syslog {
  enabled = false
}
wait {
  min = "5s"
  max = "10s"
}
max_stale = "10m"

template {
  source = "/etc/consul-templates/bar.tpl"
  destination = "/tmp/bar.txt"
  backup = false
  command = "whoami"
}

template {
  source = "/etc/consul-templates/foo.tpl"
  destination = "/tmp/foo.txt"
  backup = false
}

/etc/consul-templates/foo.tpl
{{ key "foofoo" }}

/etc/consul-templates/bar.tpl
{{ key "foo" }}
{{ key "bar" }}
{{ key "baz" }}
{{ key "api" }}
{{ key "key" }}
{{ key "name" }}

Command

/opt/consul/bin/consul-template -config /etc/consul-template.hcl -config /etc/consul-template.d/

Debug output

one-template.log https://gist.github.com/alexcreek/c9dd1b767ac79446f0f4bce678c891af
two-templates.log https://gist.github.com/alexcreek/27d2cd677c2261a3a5dfe8b916ec8644

Expected behavior

Expected behavior is not clear. I'd expect that configuring one or more templates would produce the same effect. From the docs and code comments, I can't tell whether wait controls waiting for cluster stability or a pause between data changes and rendering templates.

Actual behavior

With one template configured and using the global wait time from the Readme (min:5s, max:10s), a template is rendered once and only once. If the rendered file is changed, consul-template does not render it again.

With two templates and the same global wait time (min:5s, max:10s), the templates are rendered continually according to the min wait time. If the rendered file is changed, consul-template renders the file again. Also, debug output shows repeated rendering messages even when no template is being rendered.

With two templates and no global wait time configured, the templates are rendered once and only once.

Steps to reproduce

1. Configure more than one template and a global wait time
2. Once templates are rendered to files, modify contents of the files
3. Wait the min wait duration and the file contents will be rendered again

[sodabrew]

Does the command also get executed each time the file is rendered without changes since the previous rendering?

Linking to #1140. Duplicate?

[pearkes]

It is worth noting that rendering does not always mean writing to disk, or as @sodabrew is asking, executing something specified in command.

Yeah could well be a duplicate of #1140, maybe you can look at that @alexcreek?

[sodabrew]

See also #1057 filed in December 2017. Note my investigation at #1043 (comment) continues to point at #988 as the refactor that seems to have introduced these cases/races.

[alexcreek]

Oh. Yea, this is the same problem as #1140. Looking closer at that issue, the debug logging shows 2 templates in-use as well. This condition is only triggered when 2 or more templates are configured and there's a global wait or multiple templates have their own wait.

The command is not executed on every render. Only when the rendered file's contents are modified.

[sodabrew]

The command is not executed on every render. Only when the rendered file's contents are modified.

Thanks! Speaking as a user, this is the most important consideration for me in evaluating 0.20.0 vs. 0.19.x. I'm rendering an haproxy template, and bouncing haproxy is disruptive and should only happen when needed.

[pearkes]

Thanks, I agree this would be very unwanted it if actually ran the command on every render...currently it is just causing useless cycles that can use resources it doesn't actually need to. But as I talk about it in #1140 I think that is a side-effect (an unfortunate one) of the current design and not a simple fix, but happy to be proven wrong on that as well 😄.

Closing as a duplicate of #1140.