Update "yaml" code-block references with "jinja" where needed

There are many `.. code-block: yaml` definitions that should really
be `.. code-block: jinja` definitions. This commit cleans up some
of those and removes warnings like these from the doc build:

```
WARNING: Could not lex literal_block as "yaml". Highlighting skipped.
```

doc/faq.rst

@@ -268,7 +268,7 @@ derivatives start the service after the package installation by default.
 To prevent this, we need to create policy layer which will prevent the Minion
 service to restart right after the upgrade:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {%- if grains['os_family'] == 'Debian' %}
 
@@ -316,7 +316,7 @@ Restart using states
 Now we can apply the workaround to restart the Minion in reliable way.
 The following example works on both UNIX-like and Windows operating systems:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     Restart Salt Minion:
       cmd.run:
@@ -333,7 +333,7 @@ However, it requires more advanced tricks to upgrade from legacy version of
 Salt (before ``2016.3.0``), where executing commands in the background is not
 supported:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     Restart Salt Minion:
       cmd.run:

doc/topics/jinja/index.rst

@@ -18,7 +18,7 @@ are run.
 The most basic usage of Jinja in state files is using control structures to
 wrap conditional or redundant state elements:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% if grains['os'] != 'FreeBSD' %}
     tcsh:
@@ -43,7 +43,7 @@ Writing **if-else** blocks can lead to very redundant state files however. In
 this case, using :ref:`pillars<pillar>`, or using a previously
 defined variable might be easier:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% set motd = ['/etc/motd'] %}
     {% if grains['os'] == 'Debian' %}
@@ -61,7 +61,7 @@ list of MOTD files to update, adding a state block for each file.
 
 The filter_by function can also be used to set variables based on grains:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
    {% set auditd = salt['grains.filter_by']({
    'RedHat': { 'package': 'audit' },
@@ -76,7 +76,7 @@ Include and Import
 Includes and imports_ can be used to share common, reusable state configuration
 between state files and between files.
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% from 'lib.sls' import test %}
 
@@ -85,7 +85,7 @@ state element, from the file ``lib.sls``. In the case that the included file
 performs checks again grains, or something else that requires context, passing
 the context into the included file is required:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% from 'lib.sls' import test with context %}
 
@@ -95,7 +95,7 @@ Including Context During Include/Import
 By adding ``with context`` to the include/import directive, the
 current context can be passed to an included/imported template.
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% import 'openssl/vars.sls' as ssl with context %}
 
@@ -110,7 +110,7 @@ mini-templates to repeat blocks of strings with a few parameterized variables.
 Be aware that stripping whitespace from the template block, as well as
 contained blocks, may be necessary to emulate a variable return from the macro.
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     # init.sls
     {% from 'lib.sls' import pythonpkg with context %}
@@ -123,7 +123,7 @@ contained blocks, may be necessary to emulate a variable return from the macro.
       pkg.installed:
         - name: {{ pythonpkg('fabric') }}
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     # lib.sls
     {% macro pythonpkg(pkg) -%}
@@ -161,13 +161,13 @@ strftime
   :ref:`exhaustive list <python2:strftime-strptime-behavior>` can be found in
   the official Python documentation.
 
-  .. code-block:: yaml
+  .. code-block:: jinja
 
       {% set curtime = None | strftime() %}
 
   Fuzzy dates require the `timelib`_ Python module is installed.
 
-  .. code-block:: yaml
+  .. code-block:: jinja
 
       {{ "2002/12/25"|strftime("%y") }}
       {{ "1040814000"|strftime("%Y-%m-%d") }}
@@ -184,7 +184,7 @@ yaml_encode
   unicode.  It will *not* work for multi-objects such as sequences or
   maps.
 
-  .. code-block:: yaml
+  .. code-block:: jinja
 
       {%- set bar = 7 %}
       {%- set baz = none %}
@@ -209,7 +209,7 @@ yaml_dquote
   resulting string will be emitted with opening and closing double
   quotes.
 
-  .. code-block:: yaml
+  .. code-block:: jinja
 
       {%- set bar = '"The quick brown fox . . ."' %}
       {%- set baz = 'The word of the day is "salty".' %}
@@ -249,7 +249,7 @@ Jinja_ can be used in the same way in managed files:
             - context:
                 bind: 127.0.0.1
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     # lib.sls
     {% set port = 6379 %}
@@ -327,7 +327,7 @@ dictionary of :term:`execution function <Execution Function>`.
 
 .. versionadded:: 2014.7.0
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     # The following two function calls are equivalent.
     {{ salt['cmd.run']('whoami') }}
@@ -341,7 +341,7 @@ in the current Jinja context.
 
 .. versionadded:: 2014.7.0
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     Context is: {{ show_full_context() }}
 
@@ -356,7 +356,7 @@ distribute to Salt minions.
 Functions in custom execution modules are available in the Salt execution
 module dictionary just like the built-in execution modules:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {{ salt['my_custom_module.my_custom_function']() }}
 

doc/topics/pillar/index.rst

@@ -90,7 +90,7 @@ by their ``os`` grain:
 
 ``/srv/pillar/packages.sls``
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% if grains['os'] == 'RedHat' %}
     apache: httpd
@@ -116,13 +116,13 @@ of ``Foo Industries``.
 Consequently this data can be used from within modules, renderers, State SLS
 files, and more via the shared pillar :ref:`dict <python2:typesmapping>`:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     apache:
       pkg.installed:
         - name: {{ pillar['apache'] }}
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     git:
       pkg.installed:
@@ -155,7 +155,7 @@ And the actual pillar file at '/srv/pillar/common_pillar.sls':
     environment has its own top file, the jinja placeholder ``{{ saltenv }}``
     can be used in place of the environment name:
 
-    .. code-block:: yaml
+    .. code-block:: jinja
 
         {{ saltenv }}:
           '*':

doc/topics/reactor/index.rst

@@ -75,7 +75,7 @@ They differ because of the addition of the ``tag`` and ``data`` variables.
 
 Here is a simple reactor sls:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% if data['id'] == 'mysql1' %}
     highstate_run:
@@ -92,7 +92,7 @@ API and the runner system.  In this example, a command is published to the
 ``mysql1`` minion with a function of :py:func:`state.apply
 <salt.modules.state.apply_>`. Similarly, a runner can be called:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% if data['data']['orchestrate'] == 'refresh' %}
     orchestrate_run:
@@ -145,7 +145,7 @@ so using the Reactor to kick off an Orchestrate run is a very common pairing.
 
 For example:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     # /etc/salt/master.d/reactor.conf
     # A custom event containing: {"foo": "Foo!", "bar: "bar*", "baz": "Baz!"}
@@ -153,7 +153,7 @@ For example:
       - myco/custom/event:
         - /srv/reactor/some_event.sls
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     # /srv/reactor/some_event.sls
     invoke_orchestrate_file:
@@ -163,7 +163,7 @@ For example:
             event_tag: {{ tag }}
             event_data: {{ data | json() }}
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     # /srv/salt/orch/do_complex_thing.sls
     {% set tag = salt.pillar.get('event_tag') %}
@@ -463,7 +463,7 @@ from the event to the state file via inline Pillar.
 
 :file:`/srv/salt/haproxy/react_new_minion.sls`:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% if data['act'] == 'accept' and data['id'].startswith('web') %}
     add_new_minion_to_pool:
@@ -507,7 +507,7 @@ won't yet direct traffic to it.
 
 :file:`/srv/salt/haproxy/refresh_pool.sls`:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% set new_minion = salt['pillar.get']('new_minion') %}
 
@@ -557,7 +557,7 @@ authentication every ten seconds by default.
 
 :file:`/srv/reactor/auth-pending.sls`:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {# Ink server failed to authenticate -- remove accepted key #}
     {% if not data['result'] and data['id'].startswith('ink') %}
@@ -583,7 +583,7 @@ Ink servers in the master configuration.
 
 :file:`/srv/reactor/auth-complete.sls`:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {# When an Ink server connects, run state.apply. #}
     highstate_run:
@@ -613,7 +613,7 @@ each minion fires when it first starts up and connects to the master.
 On the master, create **/srv/reactor/sync_grains.sls** with the following
 contents:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     sync_grains:
       local.saltutil.sync_grains:

doc/topics/targeting/nodegroups.rst

@@ -122,7 +122,7 @@ example, to check if a minion is in the 'webserver' nodegroup:
     nodegroups:
       webserver: 'G@os:Debian and L@minion1,minion2'
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% if grains.id in salt['pillar.get']('master:nodegroups:webserver', [])
     and grains.os in salt['pillar.get']('master:nodegroups:webserver', []) %}

doc/topics/tutorials/starting_states.rst

@@ -367,7 +367,7 @@ for the Grains to be accessed from within the template. A few examples:
 
 ``apache/init.sls:``
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     apache:
       pkg.installed:
@@ -411,7 +411,7 @@ a MooseFS distributed filesystem chunkserver:
 
 ``moosefs/chunk.sls:``
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     include:
       - moosefs

doc/topics/tutorials/states_pt3.rst

@@ -93,7 +93,7 @@ variable in a Salt state.
 
    MYENVVAR="world" salt-call state.template test.sls
 
-.. code-block:: yaml
+.. code-block:: jinja
 
    Create a file with contents from an environment variable:
      file.managed:
@@ -102,7 +102,7 @@ variable in a Salt state.
 
 Error checking:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
    {% set myenvvar = salt['environ.get']('MYENVVAR') %}
    {% if myenvvar %}

doc/topics/tutorials/states_pt4.rst

@@ -144,7 +144,7 @@ And finally, the SLS to deploy the website:
 
 ``/srv/salt/prod/webserver/foobarcom.sls:``
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% if pillar.get('webserver_role', '') %}
     /var/www/foobarcom:

salt/modules/cmdmod.py

@@ -805,7 +805,7 @@ def run(cmd,
 
         One can still use the existing $PATH by using a bit of Jinja:
 
-        .. code-block:: yaml
+        .. code-block:: jinja
 
             {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}
 
@@ -1013,7 +1013,7 @@ def shell(cmd,
 
         One can still use the existing $PATH by using a bit of Jinja:
 
-        .. code-block:: yaml
+        .. code-block:: jinja
 
             {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}
 
@@ -1198,7 +1198,7 @@ def run_stdout(cmd,
 
         One can still use the existing $PATH by using a bit of Jinja:
 
-        .. code-block:: yaml
+        .. code-block:: jinja
 
             {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}
 
@@ -1379,7 +1379,7 @@ def run_stderr(cmd,
 
         One can still use the existing $PATH by using a bit of Jinja:
 
-        .. code-block:: yaml
+        .. code-block:: jinja
 
             {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}
 
@@ -1561,7 +1561,7 @@ def run_all(cmd,
 
         One can still use the existing $PATH by using a bit of Jinja:
 
-        .. code-block:: yaml
+        .. code-block:: jinja
 
             {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}
 
@@ -1760,7 +1760,7 @@ def retcode(cmd,
 
         One can still use the existing $PATH by using a bit of Jinja:
 
-        .. code-block:: yaml
+        .. code-block:: jinja
 
             {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}
 
@@ -1996,7 +1996,7 @@ def script(source,
 
         One can still use the existing $PATH by using a bit of Jinja:
 
-        .. code-block:: yaml
+        .. code-block:: jinja
 
             {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}
 
@@ -2221,7 +2221,7 @@ def script_retcode(source,
 
         One can still use the existing $PATH by using a bit of Jinja:
 
-        .. code-block:: yaml
+        .. code-block:: jinja
 
             {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}
 
@@ -2497,7 +2497,7 @@ def run_chroot(root,
 
         One can still use the existing $PATH by using a bit of Jinja:
 
-        .. code-block:: yaml
+        .. code-block:: jinja
 
             {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}
 
@@ -2952,7 +2952,7 @@ def powershell(cmd,
 
         One can still use the existing $PATH by using a bit of Jinja:
 
-        .. code-block:: yaml
+        .. code-block:: jinja
 
             {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}
 
@@ -3138,7 +3138,7 @@ def run_bg(cmd,
 
         One can still use the existing $PATH by using a bit of Jinja:
 
-        .. code-block:: yaml
+        .. code-block:: jinja
 
             {% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}
 

salt/modules/file.py

@@ -5724,7 +5724,7 @@ def pardir():
 
     This can be useful when constructing Salt Formulas.
 
-    .. code-block:: yaml
+    .. code-block:: jinja
 
         {% set pardir = salt['file.pardir']() %}
         {% set final_path = salt['file.join']('subdir', pardir, 'confdir') %}
@@ -5746,7 +5746,7 @@ def normpath(path):
 
     This can be useful at the CLI but is frequently useful when scripting.
 
-    .. code-block:: yaml
+    .. code-block:: jinja
 
         {%- from salt['file.normpath'](tpldir + '/../vars.jinja') import parent_vars %}
 
@@ -5767,7 +5767,7 @@ def basename(path):
 
     This can be useful at the CLI but is frequently useful when scripting.
 
-    .. code-block:: yaml
+    .. code-block:: jinja
 
         {%- set filename = salt['file.basename'](source_file) %}
 
@@ -5788,7 +5788,7 @@ def dirname(path):
 
     This can be useful at the CLI but is frequently useful when scripting.
 
-    .. code-block:: yaml
+    .. code-block:: jinja
 
         {%- from salt['file.dirname'](tpldir) + '/vars.jinja' import parent_vars %}
 
@@ -5810,7 +5810,7 @@ def join(*args):
     This can be useful at the CLI but is frequently useful when scripting
     combining path variables:
 
-    .. code-block:: yaml
+    .. code-block:: jinja
 
         {% set www_root = '/var' %}
         {% set app_dir = 'myapp' %}

salt/modules/match.py

@@ -320,7 +320,7 @@ def filter_by(lookup, expr_form='compound', minion_id=None):
 
     Pillar Example:
 
-    .. code-block:: yaml
+    .. code-block:: jinja
 
         # Filter the data for the current minion into a variable:
         {% set roles = salt['match.filter_by']({

salt/modules/mine.py

@@ -241,7 +241,7 @@ def get(tgt, fun, expr_form='glob', exclude_minion=False):
         :py:func:`saltutil.runner <salt.modules.saltutil.runner>` module. For
         example:
 
-        .. code-block:: yaml
+        .. code-block:: jinja
 
             {% set minion_ips = salt.saltutil.runner('mine.get',
                 tgt='*',

salt/modules/nacl.py

@@ -50,7 +50,7 @@ When the key is defined in the master config you can use it from the nacl runner
 
 Now you can create a pillar with protected data like:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     pillarexample:
         user: root
@@ -58,7 +58,7 @@ Now you can create a pillar with protected data like:
 
 Or do something interesting with grains like:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     salt-call nacl.enc minionname:dbrole
     AL24Z2C5OlkReer3DuQTFdrNLchLuz3NGIhGjZkLtKRYry/b/CksWM8O9yskLwH2AGVLoEXI5jAa
@@ -92,7 +92,7 @@ Pillar data should look the same, even though the secret will be quite long. How
 multiline encrypted secrets from pillar in a state, use the following format to avoid issues with /n
 creating extra whitespace at the beginning of each line in the cert file:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     secret.txt:
         file.managed:

salt/netapi/rest_cherrypy/app.py

@@ -2387,7 +2387,7 @@ class Webhook(object):
 
         And finally deploy the new build:
 
-        .. code-block:: yaml
+        .. code-block:: jinja
 
             {% set secret_key = data.get('headers', {}).get('X-My-Secret-Key') %}
             {% set build = data.get('post', {}) %}

salt/pillar/pepa.py

@@ -211,7 +211,7 @@ This was designed to be run as a build job in Jenkins or similar tool. You can p
 
 **File Example: host/validation/network.yaml**
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     network..dns..search:
       type: list