Answers: <p>Given how much time I spent weeks ago struggling with a closely-related issue, I wish I'd figured this out sooner.</p>
  
  <p>The solution appears to be to use <a href="https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.cp.html#salt.modules.cp.get_template" rel="noreferrer"><code>salt.modules.cp.get_template</code></a> to have the Salt minion retrieve the file, render it through the templating engine and place it in a readable place:</p>
  
  <pre><code># salt my-minion-id cp.get_template salt://network/init.sls /root/network.sls template=jinja
  my-minion-id:
      /root/network.sls
  </code></pre>
  
  <p>From there, you connect to the <code>my-minion-id</code> host and examine the file you placed at <code>/root/network.sls</code>.</p>
  
  <p>This makes sense; <code>salt.renderers.jinja</code> is in the <code>salt.renderers</code> namespace, while the modules you have access to from the CLI are in the <code>salt.modules</code> namespace.</p>
  
  <p>It also makes sense from a data visibility standpoint; template rendering happens on the <em>minion</em>, 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.)</p>
  
  <p><strong>edit:</strong> @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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-04-07T15:13:31.337Z
Answers: This answer seems to be more useful for debugging errors induced by jinja since it provides the text output after jinja processing, before compilation. Calling slsutil.render attempts to compile the template and if the fails (the motivation for the original question) then it not emit output that is useful for determining what kind of mess is being produced by Jinja.
Answers: Terry Burton
Answers: CC BY-SA 4.0
Answers: 2020-09-18T10:44:58.287Z
Answers: If your master is a minion (which seems to be a good idea, since everything in salt, even docs, runs on a minion) you can do `salt-call cp.get_template salt://foo.sls /dev/stdout`
Answers: emorris
Answers: CC BY-SA 4.0
Answers: 2022-01-07T23:31:45.693Z
Answers: This definitely seems the most useful way for seeing what the rendered-to-text output of an SLS file is after Jinja processing. One gotcha is that it always uses `pillarenv=base` and the normal override mechanism (specifying pillarenv on the command line) does not work as far as I can tell. Workaround is to update the config so `pillarenv=base` temporarily, which is a pain but does work.
Answers: Matthew Newton
Answers: CC BY-SA 3.0
Answers: 2017-05-12T20:51:29.143Z
Answers: 2017-05-24T11:59:57.053Z
Answers: 2017-05-24T11:59:57.053Z
Answers: Michael Mol
Answers: <p>Check out the <a href="https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.slsutil.html" rel="noreferrer">slsutil.renderer</a> module.</p>
  
  <p>This should do what you want</p>
  
  <pre><code>salt my-minion-id slsutil.renderer /srv/salt/network/init.sls 'jinja'
  </code></pre>
  
  <p>This module just calls the compile_template function directly for you.</p>
  
  <p>Edit: /srv/salt/network/init.sls is the path on the minion, if you are not targeting the master as your minion, you will probably need to do the following.</p>
  
  <pre><code>salt minion-id cp.cache_file salt://network/init.sls
  salt minion-id slsutil.renderer /var/cache/salt/minion/files/base/network/init.sls
  </code></pre>
  
  <p>or point to whatever file that cache_file spits out.</p>
  
  <p>If you are on 2018.3 or newer, you can just specify <code>salt://network/init.sls</code></p>
  
Answers: CC BY-SA 4.0
Answers: 2018-10-26T12:55:18.347Z
Answers: But what path is /srv/salt/network ? Is it the path on the master? The minion?
Answers: Mrten
Answers: CC BY-SA 4.0
Answers: 2018-10-27T13:04:35.297Z
Answers: It is a path on the minion.
  
  You can do `salt minion-id cp.cache_file salt://network/init.sls` and then run slsutil.renderer against the file it spits back after being cached on the minion, or starting in 2018.3, you can just specify `salt://network/init.sls`
Answers: gtmanfred
Answers: CC BY-SA 4.0
Answers: 2020-04-07T15:17:45.010Z
Answers: Unless I'm misunderstanding, or something differs in my environment, slsutil.render attempts to compile the template and outputs the results. That lets you see the final resulting state, but it isn't useful for examining the output of jinja that results is an invalid state, which is the question being asked.
Answers: Terry Burton
Answers: CC BY-SA 4.0
Answers: 2020-04-08T16:15:01.033Z
Answers: yes, but you can just print out the jinja object, or template it to yaml and dump it so that you can inspect the data in the jinja object.
Answers: gtmanfred
Answers: CC BY-SA 4.0
Answers: 2020-04-12T13:56:50.833Z
Answers: slsutil.render renders then compiles states and there does not appear to be a way to terminate the pipeline prior to compilation. so I don't see how it solves "In 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."
  
  If you know otherwise then I would be interested to see an example (specifically with Jinja that produces a broken state) because an irksome thing with cp.get_template is that it requires an output FD and so it isn't effective when called by salt from a master as /dev/stdout isn't available.
Answers: Terry Burton
Answers: CC BY-SA 4.0
Answers: 2017-05-23T22:34:18.897Z
Answers: 2018-10-27T13:07:02.217Z
Answers: 2018-10-27T13:07:02.217Z
Answers: gtmanfred
Body: <p>I have a templated <code>SLS</code> in Salt I'm trying to build, but it's emitting invalid syntax, which is resulting in errors such as:</p>
  
  <pre><code>my-minion-id:
      - State 'system' in SLS 'network' is not formed as a list
  </code></pre>
  
  <p>In principle, it should be possible to, <em>somehow</em> examine the output of the Jinja template before it attempts to parse the output as an <code>SLS</code> file. There exists a Python module for the Jinja renderer<a href="https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.jinja.html#module-salt.renderers.jinja" rel="noreferrer"><code>salt.renderers.jinja</code></a>, but if I attempt to execute it on the CLI, I get an error:</p>
  
  <pre><code># 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 code
  </code></pre>
  
  <p>How can I see the output of my template? It seems absurd it should be this difficult to debug.</p>
  
Tags: <salt><jinja>
Title: How to examine Jinja output in Saltstack?
UserDisplayName: Michael Mol
ThreadText: # How to examine Jinja output in Saltstack?
  
  (Asked by: username_0 on 2017-05-12)
  
  I have a templated `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 list
  
  ```
  
  In 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 renderer[`salt.renderers.jinja`](https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.jinja.html#module-salt.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 code
  
  ```
  
  How can I see the output of my template? It seems absurd it should be this difficult to debug.
  
  **Tags:** salt, jinja
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_4 on 2017-05-23. Score: 14 | Accepted answer
  
  Check out the [slsutil.renderer](https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.slsutil.html) module.
  
  This should do what you want
  
  ```
  salt my-minion-id slsutil.renderer /srv/salt/network/init.sls 'jinja'
  
  ```
  
  This module just calls the compile\_template function directly for you.
  
  Edit: /srv/salt/network/init.sls is the path on the minion, if you are not targeting the master as your minion, you will probably need to do the following.
  
  ```
  salt minion-id cp.cache_file salt://network/init.sls
  salt minion-id slsutil.renderer /var/cache/salt/minion/files/base/network/init.sls
  
  ```
  
  or point to whatever file that cache\_file spits out.
  
  If you are on 2018.3 or newer, you can just specify `salt://network/init.sls`
  
  > **Comments:**
  > **username_5**: But what path is /srv/salt/network ? Is it the path on the master? The minion?  
  > **username_4**: It is a path on the minion.  You can do `salt minion-id cp.cache_file salt://network/init.sls` and then run slsutil.renderer against the file it spits back after being cached on the minion, or starting in 2018.3, you can just specify `salt://network/init.sls`  
  > **username_1**: Unless I'm misunderstanding, or something differs in my environment, slsutil.render attempts to compile the template and outputs the results. That lets you see the final resulting state, but it isn't useful for examining the output of jinja that results is an invalid state, which is the question being asked.  
  > **username_4**: yes, but you can just print out the jinja object, or template it to yaml and dump it so that you can inspect the data in the jinja object.  
  > **username_1**: slsutil.render renders then compiles states and there does not appear to be a way to terminate the pipeline prior to compilation. so I don't see how it solves "In 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."  If you know otherwise then I would be interested to see an example (specifically with Jinja that produces a broken state) because an irksome thing with cp.get_template is that it requires an output FD and so it isn't effective when called by salt from a master as /dev/stdout isn't available.  
  
  ---
  
  ### Answer by username_0 on 2017-05-12. Score: 14
  
  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 [`salt.modules.cp.get_template`](https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.cp.html#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.sls
  
  ```
  
  From 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:** @username_4'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.
  
  > **Comments:**
  > **username_1**: This answer seems to be more useful for debugging errors induced by jinja since it provides the text output after jinja processing, before compilation. Calling slsutil.render attempts to compile the template and if the fails (the motivation for the original question) then it not emit output that is useful for determining what kind of mess is being produced by Jinja.  
  > **username_2**: If your master is a minion (which seems to be a good idea, since everything in salt, even docs, runs on a minion) you can do `salt-call cp.get_template salt://foo.sls /dev/stdout`  
  > **username_3**: This definitely seems the most useful way for seeing what the rendered-to-text output of an SLS file is after Jinja processing. One gotcha is that it always uses `pillarenv=base` and the normal override mechanism (specifying pillarenv on the command line) does not work as far as I can tell. Workaround is to update the config so `pillarenv=base` temporarily, which is a pain but does work.  
  
  ---
  
  