An unexpected trap with variable_start_string/variable_end_string

George Shuklin
OpsOps
Published in
1 min readAug 9, 2018

--

There are two features of Ansible:

  1. Lazy evaluation of jinja2. If you set your variable foo to ‘{{some_var}}’, it’s not set to the value of some_var, instead it become a literal ‘{{some_var}}’. When some module decide to use this variable, it is evaluated.
  2. You can use variable_start_string/variable_end_string parameters of template module to change ‘mustache’ value for jinja2. Absolutely irreplaceable for templates with ‘{{‘ as part of configuration file.

Guess what would happen if you combine those two features?

If you have your variable ‘foo’ set to ‘{{some_var}}’, and you use it in the normal template, in a form ‘{{ foo }}’, it will be happily evaluated and replaced with content of some_var.

But if your template uses a different mustache (for example, <<this>>), … you can guess what you get. The literal ‘{{ some_var }}’, even after templatization.

I’ll try to report as a bug, but I feel it’s rooted too deep into Ansible to fix. (upd: reported)

Insofar I imagined only one way: use set_factmodule to re-evaluate variables.

--

--

George Shuklin
OpsOps

I work at Servers.com, most of my stories are about Ansible, Ceph, Python, Openstack and Linux. My hobby is Rust.