Merge branch '2017.7' into '2018.3'

Conflicts:
  - salt/pillar/cmd_yamlex.py

doc/conf.py

@@ -65,6 +65,7 @@ MOCK_MODULES = [
     'user',
 
     # salt core
+    'concurrent',
     'Crypto',
     'Crypto.Signature',
     'Crypto.Cipher',

doc/ref/modules/index.rst

@@ -137,7 +137,7 @@ call functions available in other execution modules.
 The variable ``__salt__`` is packed into the modules after they are loaded into
 the Salt minion.
 
-The ``__salt__`` variable is a :ref:`Python dictionary <typesmapping>`
+The ``__salt__`` variable is a :ref:`Python dictionary <python:typesmapping>`
 containing all of the Salt functions. Dictionary keys are strings representing
 the names of the modules and the values are the functions themselves.
 
@@ -176,7 +176,7 @@ Grains Data
 -----------
 
 The values detected by the Salt Grains on the minion are available in a
-:ref:`Python dictionary <typesmapping>` named ``__grains__`` and can be
+:ref:`Python dictionary <python:typesmapping>` named ``__grains__`` and can be
 accessed from within callable objects in the Python modules.
 
 To see the contents of the grains dictionary for a given system in your
@@ -288,7 +288,7 @@ Virtual module names are set using the ``__virtual__`` function and the
 ``__virtual__`` Function
 ========================
 
-The ``__virtual__`` function returns either a :ref:`string <typesseq>`,
+The ``__virtual__`` function returns either a :ref:`string <python:typesseq>`,
 :py:data:`True`, :py:data:`False`, or :py:data:`False` with an :ref:`error
 string <modules-error-info>`. If a string is returned then the module is loaded
 using the name of the string as the virtual name. If ``True`` is returned the

doc/ref/states/writing.rst

@@ -190,7 +190,7 @@ functions available in other state modules.
 The variable ``__states__`` is packed into the modules after they are loaded into
 the Salt minion.
 
-The ``__states__`` variable is a :ref:`Python dictionary <typesmapping>`
+The ``__states__`` variable is a :ref:`Python dictionary <python:typesmapping>`
 containing all of the state modules. Dictionary keys are strings representing
 the names of the modules and the values are the functions themselves.
 

doc/topics/grains/index.rst

@@ -125,8 +125,8 @@ The grains are derived by executing all of the "public" functions (i.e. those
 which do not begin with an underscore) found in the modules located in the
 Salt's core grains code, followed by those in any custom grains modules. The
 functions in a grains module must return a :ref:`Python dictionary
-<typesmapping>`, where the dictionary keys are the names of grains, and each
-key's value is that value for that grain.
+<python:typesmapping>`, where the dictionary keys are the names of grains, and
+each key's value is that value for that grain.
 
 Custom grains modules should be placed in a subdirectory named ``_grains``
 located under the :conf_master:`file_roots` specified by the master config

doc/topics/jinja/index.rst

@@ -177,7 +177,7 @@ Saltstack extends `builtin filters`_ with these custom filters:
 
 Converts any time related object into a time based string. It requires valid
 strftime directives. An exhaustive list can be found :ref:`here
-<strftime-strptime-behavior>` in the Python documentation.
+<python:strftime-strptime-behavior>` in the Python documentation.
 
 .. code-block:: jinja
 

salt/pillar/cmd_yamlex.py

@@ -1,15 +1,12 @@
 # -*- coding: utf-8 -*-
 '''
-Execute a command and read the output as YAMLEX. The YAMLEX data is then
-directly overlaid onto the minion's Pillar data
+Execute a command and read the output as YAMLEX.
+
+The YAMLEX data is then directly overlaid onto the minion's Pillar data
 '''
 
-# Don't "fix" the above docstring to put it on two lines, as the sphinx
-# autosummary pulls only the first line for its description.
-
-from __future__ import absolute_import, print_function, unicode_literals
-
 # Import python libs
+from __future__ import absolute_import, print_function, unicode_literals
 import logging
 
 # Import salt libs

salt/pillar/makostack.py

@@ -103,7 +103,7 @@ would actually end up in pillar after all merging was complete:
           - baz
 
 MakoStack configuration files
--------------------------------
+-----------------------------
 
 The config files that are referenced in the above ``ext_pillar`` configuration
 are mako templates which must render as a simple ordered list of ``yaml``

salt/pillar/mysql.py

@@ -12,7 +12,7 @@ This module is a concrete implementation of the sql_base ext_pillar for MySQL.
 :platform: all
 
 Configuring the mysql ext_pillar
-=====================================
+================================
 
 Use the 'mysql' key under ext_pillar for configuration of queries.
 
@@ -22,7 +22,7 @@ mysql.pass, mysql.port, mysql.host) for database connection info.
 Required python modules: MySQLdb
 
 Complete example
-=====================================
+================
 
 .. code-block:: yaml
 

salt/pillar/postgres.py

@@ -8,8 +8,8 @@ Retrieve Pillar data by doing a postgres query
 :depends: psycopg2
 :platform: all
 
-Complete example
-=====================================
+Complete Example
+================
 
 .. code-block:: yaml
 

salt/pillar/sql_base.py

@@ -10,7 +10,7 @@ It exposes a python ABC that can be subclassed for new database providers.
 :platform: all
 
 Theory of sql_base ext_pillar
-=====================================
+=============================
 
 Ok, here's the theory for how this works...
 
@@ -32,7 +32,7 @@ You can retrieve as many fields as you like, how they get used depends on the
 exact settings.
 
 Configuring a sql_base ext_pillar
-=====================================
+=================================
 
 The sql_base ext_pillar cannot be used directly, but shares query configuration
 with its implementations. These examples use a fake 'sql_base' adapter, which

salt/pillar/sqlcipher.py

@@ -37,8 +37,8 @@ Example configuration
       pass: strong_pass_phrase
       timeout: 5.0
 
-Complete example
-=================
+Complete Example
+================
 
 .. code-block:: yaml