Open mendelskiv93 opened 3 weeks ago
the problem with that approach is that Consul Template is a two-pass implementation. The first time it reads the template to figure out what services/keys to watch, then it queries Consul. So having some kind of range/loop in the template is rather difficult with the current implementation. That's why its suggested having multiple Consul Template instances - one that queries the master services list and renders a template that is a ctmpl, and then another Consul Template instance that consumes that instance.
So I guess the question is: why is anything return from a first pass?
Version
v0.39.1
We are using
consul-template
in Exec mode:to generate Nginx configuration files dynamically based on service metadata stored in Consul. Our consul-template renders tagged services and generates upstream configurations.
Templating is triggered by changes in consul catalog and on each trigger, all ~200 available services are fetched and only ~130 tagged ones are rendered.
For a simplicity, I created a small environment with only 2 tagged services and here is the trace.log.
Problem
Found a bug while extending our template with plugin which triggers a python script for moving decommissioned sites
.conf
files to a folder.Upon restarting the ssl-proxy service or running consul-template first time even through CLI:
the initial fetch cycle renders with empty data.
Looking at the code:
and some other issues:
gaves ma an idea of a first-pass run but I cannot really figure out why is this happening when there is a successful response with all services:
before the first rendering:
Steps to reproduce
My results consistently show the same pattern: an initial empty file followed by a correct file rendered within the same run. After that,
consul-template
continues to run and render normally.Also, using
--wait
seems to have no impact on initial run.