snippetModerate
How to examine Jinja output in Saltstack?
Viewed 0 times
examinesaltstackoutputhowjinja
Problem
I have a templated
In principle, it should be possible to, somehow examine the output of the Jinja template before it attempts to parse the output as an
How can I see the output of my template? It seems absurd it should be this difficult to debug.
SLS in Salt I'm trying to build, but it's emitting invalid syntax, which is resulting in errors such as:my-minion-id:
- State 'system' in SLS 'network' is not formed as a listIn principle, it should be possible to, somehow examine the output of the Jinja template before it attempts to parse the output as an
SLS file. There exists a Python module for the Jinja renderersalt.renderers.jinja, but if I attempt to execute it on the CLI, I get an error:# salt my-minion-id salt.renderers.jinja.render /srv/salt/network/init.sls
my-minion-id:
'salt.renderers.jinja.render' is not available.
ERROR: Minions returned with non-zero exit code
# salt my-minion-id renderers.jinja.render /srv/salt/network/init.sls
my-minion-id:
'renderers.jinja.render' is not available.
ERROR: Minions returned with non-zero exit codeHow can I see the output of my template? It seems absurd it should be this difficult to debug.
Solution
Given how much time I spent weeks ago struggling with a closely-related issue, I wish I'd figured this out sooner.
The solution appears to be to use
From there, you connect to the
This makes sense;
It also makes sense from a data visibility standpoint; template rendering happens on the minion, where grains and such are available, and I've yet to see a module that executes minion code return arbitrary output to the master (for view on the CLI, for example); the returned data is invariably well-structured and concise. (There may be such a module, but I don't know what it is. It would be a preferable solution to dropping test files onto a minion.)
edit: @gtmanfred's answer is far better and more direct, and I've accepted that one. I'm leaving this one here for informative purposes. It's not the best solution, but it does still work.
The solution appears to be to use
salt.modules.cp.get_template to have the Salt minion retrieve the file, render it through the templating engine and place it in a readable place:# salt my-minion-id cp.get_template salt://network/init.sls /root/network.sls template=jinja
my-minion-id:
/root/network.slsFrom there, you connect to the
my-minion-id host and examine the file you placed at /root/network.sls.This makes sense;
salt.renderers.jinja is in the salt.renderers namespace, while the modules you have access to from the CLI are in the salt.modules namespace.It also makes sense from a data visibility standpoint; template rendering happens on the minion, where grains and such are available, and I've yet to see a module that executes minion code return arbitrary output to the master (for view on the CLI, for example); the returned data is invariably well-structured and concise. (There may be such a module, but I don't know what it is. It would be a preferable solution to dropping test files onto a minion.)
edit: @gtmanfred's answer is far better and more direct, and I've accepted that one. I'm leaving this one here for informative purposes. It's not the best solution, but it does still work.
Code Snippets
# salt my-minion-id cp.get_template salt://network/init.sls /root/network.sls template=jinja
my-minion-id:
/root/network.slsContext
StackExchange DevOps Q#1156, answer score: 14
Revisions (0)
No revisions yet.