Merge branch 'develop' into fix_freebsdkmod_remove

.ci/docs

@@ -0,0 +1,46 @@
+pipeline {
+    agent { label 'docs' }
+    environment {
+        PYENV_ROOT = "/usr/local/pyenv"
+        PATH = "$PYENV_ROOT/bin:$PATH"
+    }
+    stages {
+        stage('github-pending') {
+            steps {
+                githubNotify credentialsId: 'test-jenkins-credentials',
+                    description: 'Testing docs...',
+                    status: 'PENDING',
+                    context: "jenkins/pr/docs"
+            }
+        }
+        stage('setup') {
+            steps {
+                sh 'eval "$(pyenv init -)"; pyenv install 2.7.14 || echo "We already have this python."; pyenv local 2.7.14; pyenv shell 2.7.14'
+                sh 'eval "$(pyenv init -)"; pip install sphinx -e .'
+            }
+        }
+        stage('build') {
+            steps {
+                sh 'eval "$(pyenv init -)"; make -C doc clean html'
+                archiveArtifacts artifacts: 'doc/_build/html/'
+            }
+        }
+    }
+    post {
+        always {
+            cleanWs()
+        }
+        success {
+            githubNotify credentialsId: 'test-jenkins-credentials',
+                description: 'The docs job has passed',
+                status: 'SUCCESS',
+                context: "jenkins/pr/docs"
+        }
+        failure {
+            githubNotify credentialsId: 'test-jenkins-credentials',
+                description: 'The docs job has failed',
+                status: 'FAILURE',
+                context: "jenkins/pr/docs"
+        }
+    }
+}

.ci/kitchen-centos7-py2

@@ -0,0 +1,65 @@
+pipeline {
+    agent { label 'kitchen-slave' }
+    environment {
+        SALT_KITCHEN_PLATFORMS = "/var/jenkins/workspace/platforms.yml"
+        SALT_KITCHEN_DRIVER = "/var/jenkins/workspace/driver.yml"
+        PATH = "/usr/local/rbenv/shims/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/root/bin"
+        RBENV_VERSION = "2.4.2"
+        TEST_SUITE = "py2"
+        TEST_PLATFORM = "centos-7"
+    }
+    stages {
+        stage('github-pending') {
+            steps {
+                githubNotify credentialsId: 'test-jenkins-credentials',
+                    description: "running ${TEST_SUITE}-${TEST_PLATFORM}...",
+                    status: 'PENDING',
+                    context: "jenkins/pr/${TEST_SUITE}-${TEST_PLATFORM}"
+            }
+        }
+        stage('setup') {
+            steps {
+                sh 'bundle install --with ec2 windows --without opennebula docker'
+            }
+        }
+        stage('run kitchen') {
+            steps {
+                script { withCredentials([[$class: 'AmazonWebServicesCredentialsBinding', accessKeyVariable: 'AWS_ACCESS_KEY_ID', credentialsId: 'AWS_ACCESS_KEY_ID', secretKeyVariable: 'AWS_SECRET_ACCESS_KEY']]) {
+                    sshagent(credentials: ['jenkins-testing-ssh-key']) {
+                        sh 'ssh-add ~/.ssh/jenkins-testing.pem'
+                        sh 'bundle exec kitchen converge $TEST_SUITE-$TEST_PLATFORM || bundle exec kitchen converge $TEST_SUITE-$TEST_PLATFORM'
+                        sh 'bundle exec kitchen verify $TEST_SUITE-$TEST_PLATFORM'
+                    }
+                }}
+                archiveArtifacts artifacts: 'artifacts/xml-unittests-output/*.xml'
+            }
+            post {
+                always {
+                    script { withCredentials([[$class: 'AmazonWebServicesCredentialsBinding', accessKeyVariable: 'AWS_ACCESS_KEY_ID', credentialsId: 'AWS_ACCESS_KEY_ID', secretKeyVariable: 'AWS_SECRET_ACCESS_KEY']]) {
+                        sshagent(credentials: ['jenkins-testing-ssh-key']) {
+                            sh 'ssh-add ~/.ssh/jenkins-testing.pem'
+                            sh 'bundle exec kitchen destroy $TEST_SUITE-$TEST_PLATFORM'
+                        }
+                    }}
+                }
+            }
+        }
+    }
+    post {
+        always {
+            cleanWs()
+        }
+        success {
+            githubNotify credentialsId: 'test-jenkins-credentials',
+                description: "The ${TEST_SUITE}-${TEST_PLATFORM} job has passed",
+                status: 'SUCCESS',
+                context: "jenkins/pr/${TEST_SUITE}-${TEST_PLATFORM}"
+        }
+        failure {
+            githubNotify credentialsId: 'test-jenkins-credentials',
+                description: "The ${TEST_SUITE}-${TEST_PLATFORM} job has failed",
+                status: 'FAILURE',
+                context: "jenkins/pr/${TEST_SUITE}-${TEST_PLATFORM}"
+        }
+    }
+}

.ci/kitchen-centos7-py3

@@ -0,0 +1,65 @@
+pipeline {
+    agent { label 'kitchen-slave' }
+    environment {
+        SALT_KITCHEN_PLATFORMS = "/var/jenkins/workspace/platforms.yml"
+        SALT_KITCHEN_DRIVER = "/var/jenkins/workspace/driver.yml"
+        PATH = "/usr/local/rbenv/shims/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/root/bin"
+        RBENV_VERSION = "2.4.2"
+        TEST_SUITE = "py3"
+        TEST_PLATFORM = "centos-7"
+    }
+    stages {
+        stage('github-pending') {
+            steps {
+                githubNotify credentialsId: 'test-jenkins-credentials',
+                    description: "running ${TEST_SUITE}-${TEST_PLATFORM}...",
+                    status: 'PENDING',
+                    context: "jenkins/pr/${TEST_SUITE}-${TEST_PLATFORM}"
+            }
+        }
+        stage('setup') {
+            steps {
+                sh 'bundle install --with ec2 windows --without opennebula docker'
+            }
+        }
+        stage('run kitchen') {
+            steps {
+                script { withCredentials([[$class: 'AmazonWebServicesCredentialsBinding', accessKeyVariable: 'AWS_ACCESS_KEY_ID', credentialsId: 'AWS_ACCESS_KEY_ID', secretKeyVariable: 'AWS_SECRET_ACCESS_KEY']]) {
+                    sshagent(credentials: ['jenkins-testing-ssh-key']) {
+                        sh 'ssh-add ~/.ssh/jenkins-testing.pem'
+                        sh 'bundle exec kitchen converge $TEST_SUITE-$TEST_PLATFORM || bundle exec kitchen converge $TEST_SUITE-$TEST_PLATFORM'
+                        sh 'bundle exec kitchen verify $TEST_SUITE-$TEST_PLATFORM'
+                    }
+                }}
+                archiveArtifacts artifacts: 'artifacts/xml-unittests-output/*.xml'
+            }
+            post {
+                always {
+                    script { withCredentials([[$class: 'AmazonWebServicesCredentialsBinding', accessKeyVariable: 'AWS_ACCESS_KEY_ID', credentialsId: 'AWS_ACCESS_KEY_ID', secretKeyVariable: 'AWS_SECRET_ACCESS_KEY']]) {
+                        sshagent(credentials: ['jenkins-testing-ssh-key']) {
+                            sh 'ssh-add ~/.ssh/jenkins-testing.pem'
+                            sh 'bundle exec kitchen destroy $TEST_SUITE-$TEST_PLATFORM'
+                        }
+                    }}
+                }
+            }
+        }
+    }
+    post {
+        always {
+            cleanWs()
+        }
+        success {
+            githubNotify credentialsId: 'test-jenkins-credentials',
+                description: "The ${TEST_SUITE}-${TEST_PLATFORM} job has passed",
+                status: 'SUCCESS',
+                context: "jenkins/pr/${TEST_SUITE}-${TEST_PLATFORM}"
+        }
+        failure {
+            githubNotify credentialsId: 'test-jenkins-credentials',
+                description: "The ${TEST_SUITE}-${TEST_PLATFORM} job has failed",
+                status: 'FAILURE',
+                context: "jenkins/pr/${TEST_SUITE}-${TEST_PLATFORM}"
+        }
+    }
+}

.ci/kitchen-ubuntu1604-py2

@@ -0,0 +1,65 @@
+pipeline {
+    agent { label 'kitchen-slave' }
+    environment {
+        SALT_KITCHEN_PLATFORMS = "/var/jenkins/workspace/platforms.yml"
+        SALT_KITCHEN_DRIVER = "/var/jenkins/workspace/driver.yml"
+        PATH = "/usr/local/rbenv/shims/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/root/bin"
+        RBENV_VERSION = "2.4.2"
+        TEST_SUITE = "py2"
+        TEST_PLATFORM = "ubuntu-1604"
+    }
+    stages {
+        stage('github-pending') {
+            steps {
+                githubNotify credentialsId: 'test-jenkins-credentials',
+                    description: "running ${TEST_SUITE}-${TEST_PLATFORM}...",
+                    status: 'PENDING',
+                    context: "jenkins/pr/${TEST_SUITE}-${TEST_PLATFORM}"
+            }
+        }
+        stage('setup') {
+            steps {
+                sh 'bundle install --with ec2 windows --without opennebula docker'
+            }
+        }
+        stage('run kitchen') {
+            steps {
+                script { withCredentials([[$class: 'AmazonWebServicesCredentialsBinding', accessKeyVariable: 'AWS_ACCESS_KEY_ID', credentialsId: 'AWS_ACCESS_KEY_ID', secretKeyVariable: 'AWS_SECRET_ACCESS_KEY']]) {
+                    sshagent(credentials: ['jenkins-testing-ssh-key']) {
+                        sh 'ssh-add ~/.ssh/jenkins-testing.pem'
+                        sh 'bundle exec kitchen converge $TEST_SUITE-$TEST_PLATFORM || bundle exec kitchen converge $TEST_SUITE-$TEST_PLATFORM'
+                        sh 'bundle exec kitchen verify $TEST_SUITE-$TEST_PLATFORM'
+                    }
+                }}
+                archiveArtifacts artifacts: 'artifacts/xml-unittests-output/*.xml'
+            }
+            post {
+                always {
+                    script { withCredentials([[$class: 'AmazonWebServicesCredentialsBinding', accessKeyVariable: 'AWS_ACCESS_KEY_ID', credentialsId: 'AWS_ACCESS_KEY_ID', secretKeyVariable: 'AWS_SECRET_ACCESS_KEY']]) {
+                        sshagent(credentials: ['jenkins-testing-ssh-key']) {
+                            sh 'ssh-add ~/.ssh/jenkins-testing.pem'
+                            sh 'bundle exec kitchen destroy $TEST_SUITE-$TEST_PLATFORM'
+                        }
+                    }}
+                }
+            }
+        }
+    }
+    post {
+        always {
+            cleanWs()
+        }
+        success {
+            githubNotify credentialsId: 'test-jenkins-credentials',
+                description: "The ${TEST_SUITE}-${TEST_PLATFORM} job has passed",
+                status: 'SUCCESS',
+                context: "jenkins/pr/${TEST_SUITE}-${TEST_PLATFORM}"
+        }
+        failure {
+            githubNotify credentialsId: 'test-jenkins-credentials',
+                description: "The ${TEST_SUITE}-${TEST_PLATFORM} job has failed",
+                status: 'FAILURE',
+                context: "jenkins/pr/${TEST_SUITE}-${TEST_PLATFORM}"
+        }
+    }
+}

.ci/kitchen-ubuntu1604-py3

@@ -0,0 +1,65 @@
+pipeline {
+    agent { label 'kitchen-slave' }
+    environment {
+        SALT_KITCHEN_PLATFORMS = "/var/jenkins/workspace/platforms.yml"
+        SALT_KITCHEN_DRIVER = "/var/jenkins/workspace/driver.yml"
+        PATH = "/usr/local/rbenv/shims/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/root/bin"
+        RBENV_VERSION = "2.4.2"
+        TEST_SUITE = "py3"
+        TEST_PLATFORM = "ubuntu-1604"
+    }
+    stages {
+        stage('github-pending') {
+            steps {
+                githubNotify credentialsId: 'test-jenkins-credentials',
+                    description: "running ${TEST_SUITE}-${TEST_PLATFORM}...",
+                    status: 'PENDING',
+                    context: "jenkins/pr/${TEST_SUITE}-${TEST_PLATFORM}"
+            }
+        }
+        stage('setup') {
+            steps {
+                sh 'bundle install --with ec2 windows --without opennebula docker'
+            }
+        }
+        stage('run kitchen') {
+            steps {
+                script { withCredentials([[$class: 'AmazonWebServicesCredentialsBinding', accessKeyVariable: 'AWS_ACCESS_KEY_ID', credentialsId: 'AWS_ACCESS_KEY_ID', secretKeyVariable: 'AWS_SECRET_ACCESS_KEY']]) {
+                    sshagent(credentials: ['jenkins-testing-ssh-key']) {
+                        sh 'ssh-add ~/.ssh/jenkins-testing.pem'
+                        sh 'bundle exec kitchen converge $TEST_SUITE-$TEST_PLATFORM || bundle exec kitchen converge $TEST_SUITE-$TEST_PLATFORM'
+                        sh 'bundle exec kitchen verify $TEST_SUITE-$TEST_PLATFORM'
+                    }
+                }}
+                archiveArtifacts artifacts: 'artifacts/xml-unittests-output/*.xml'
+            }
+            post {
+                always {
+                    script { withCredentials([[$class: 'AmazonWebServicesCredentialsBinding', accessKeyVariable: 'AWS_ACCESS_KEY_ID', credentialsId: 'AWS_ACCESS_KEY_ID', secretKeyVariable: 'AWS_SECRET_ACCESS_KEY']]) {
+                        sshagent(credentials: ['jenkins-testing-ssh-key']) {
+                            sh 'ssh-add ~/.ssh/jenkins-testing.pem'
+                            sh 'bundle exec kitchen destroy $TEST_SUITE-$TEST_PLATFORM'
+                        }
+                    }}
+                }
+            }
+        }
+    }
+    post {
+        always {
+            cleanWs()
+        }
+        success {
+            githubNotify credentialsId: 'test-jenkins-credentials',
+                description: "The ${TEST_SUITE}-${TEST_PLATFORM} job has passed",
+                status: 'SUCCESS',
+                context: "jenkins/pr/${TEST_SUITE}-${TEST_PLATFORM}"
+        }
+        failure {
+            githubNotify credentialsId: 'test-jenkins-credentials',
+                description: "The ${TEST_SUITE}-${TEST_PLATFORM} job has failed",
+                status: 'FAILURE',
+                context: "jenkins/pr/${TEST_SUITE}-${TEST_PLATFORM}"
+        }
+    }
+}

.ci/lint

@@ -0,0 +1,66 @@
+pipeline {
+    agent { label 'pr-lint-slave' }
+    environment {
+        PYENV_ROOT = "/usr/local/pyenv"
+        PATH = "$PYENV_ROOT/bin:$PATH"
+    }
+    stages {
+        stage('github-pending') {
+            steps {
+                githubNotify credentialsId: 'test-jenkins-credentials',
+                    description: 'Testing lint...',
+                    status: 'PENDING',
+                    context: "jenkins/pr/lint"
+            }
+        }
+        stage('setup') {
+            steps {
+                sh 'eval "$(pyenv init -)"; pyenv install 2.7.14 || echo "We already have this python."; pyenv local 2.7.14; pyenv shell 2.7.14'
+                sh 'eval "$(pyenv init -)"; pip install pylint SaltPyLint'
+                sh 'eval "$(pyenv init -)"; which pylint; pylint --version'
+            }
+        }
+        stage('linting') {
+            failFast false
+            parallel {
+                stage('salt linting') {
+                    steps {
+                        sh 'eval "$(pyenv init -)"; pylint --rcfile=.testing.pylintrc --disable=W1307,str-format-in-logging setup.py salt/ | tee pylint-report.xml'
+                        archiveArtifacts artifacts: 'pylint-report.xml'
+                    }
+                }
+                stage('test linting') {
+                    steps {
+                        sh 'eval "$(pyenv init -)"; pylint --rcfile=.testing.pylintrc --disable=W0232,E1002,W1307,str-format-in-logging tests/ | tee pylint-report-tests.xml'
+                        archiveArtifacts artifacts: 'pylint-report-tests.xml'
+                    }
+                }
+            }
+        }
+    }
+    post {
+        always {
+            step([$class: 'WarningsPublisher',
+                parserConfigurations: [[
+                    parserName: 'PyLint',
+                    pattern: 'pylint-report*.xml'
+                ]],
+                unstableTotalAll: '999',
+                usePreviousBuildAsReference: true
+            ])
+            cleanWs()
+        }
+        success {
+            githubNotify credentialsId: 'test-jenkins-credentials',
+                description: 'The lint job has passed',
+                status: 'SUCCESS',
+                context: "jenkins/pr/lint"
+        }
+        failure {
+            githubNotify credentialsId: 'test-jenkins-credentials',
+                description: 'The lint job has failed',
+                status: 'FAILURE',
+                context: "jenkins/pr/lint"
+        }
+    }
+}

.github/stale.yml

@@ -1,8 +1,8 @@
 # Probot Stale configuration file
 
 # Number of days of inactivity before an issue becomes stale
-# 700 is approximately 1 year and 11 months
-daysUntilStale: 700
+# 650 is approximately 1 year and 9 months
+daysUntilStale: 650
 
 # Number of days of inactivity before a stale issue is closed
 daysUntilClose: 7

.kitchen.yml

@@ -1,6 +1,6 @@
 ---
 <% vagrant = system('gem list -i kitchen-vagrant 2>/dev/null >/dev/null') %>
-<% version = '2017.7.4' %>
+<% version = '2017.7.6' %>
 <% platformsfile = ENV['SALT_KITCHEN_PLATFORMS'] || '.kitchen/platforms.yml' %>
 <% driverfile = ENV['SALT_KITCHEN_DRIVER'] || '.kitchen/driver.yml' %>
 <% verifierfile = ENV['SALT_KITCHEN_VERIFIER'] || '.kitchen/verifier.yml' %>
@@ -31,7 +31,7 @@ provisioner:
   salt_version: latest
   salt_bootstrap_url: https://bootstrap.saltstack.com
   salt_bootstrap_options: -X -p rsync stable <%= version %>
-  log_level: debug
+  log_level: info
   sudo: true
   require_chef: false
   retry_on_exit_code:
@@ -43,23 +43,20 @@ provisioner:
     repo: git
     testingdir: /testing
   salt_copy_filter:
-    - .bundle
-    - .kitchen
-    - .kitchen.yml
-    - artifacts
-    - Gemfile
-    - Gemfile.lock
-    - README.rst
-    - .travis.yml
-    - '*.pyc'
     - __pycache__
+    - '*.pyc'
+    - .bundle
+    - .tox
+    - .kitchen
+    - artifacts
+    - Gemfile.lock
   state_top:
     base:
       "os:Windows":
         - match: grain
         - prep_windows
       "*":
-        - git.salt
+        - <%= ENV['KITCHEN_STATE'] || 'git.salt' %>
   pillars:
     top.sls:
       base:

.pylintrc

@@ -170,6 +170,7 @@ additional-builtins=__opts__,
   __proxy__,
   __serializers__,
   __reg__,
+  __executors__,
   __events__
 
 # List of strings which can identify a callback function by name. A callback

.testing.pylintrc

@@ -267,6 +267,7 @@ additional-builtins=__opts__,
   __proxy__,
   __serializers__,
   __reg__,
+  __executors__,
   __events__
 
 

conf/minion

@@ -21,6 +21,10 @@
 #proxy_username:
 #proxy_password:
 
+# List of hosts to bypass HTTP proxy. This key does nothing unless proxy_host etc is
+# configured, it does not support any kind of wildcards.
+#no_proxy: []
+
 # If multiple masters are specified in the 'master' setting, the default behavior
 # is to always try to connect to them in the order they are listed. If random_master is
 # set to True, the order will be randomized instead. This can be helpful in distributing

doc/.scripts/compile-translation-catalogs

@@ -1,7 +1,7 @@
 #!/usr/bin/env python
 # -*- coding: utf-8 -*-
 '''
-    :codeauthor: :email:`Pedro Algarvio (pedro@algarvio.me)`
+    :codeauthor: Pedro Algarvio (pedro@algarvio.me)
 
 
     compile-translation-catalogs

doc/.scripts/download-translation-catalog

@@ -1,7 +1,7 @@
 #!/usr/bin/env python
 # -*- coding: utf-8 -*-
 '''
-    :codeauthor: :email:`Pedro Algarvio (pedro@algarvio.me)`
+    :codeauthor: Pedro Algarvio (pedro@algarvio.me)
 
 
     download-translation-catalog

doc/.scripts/setup-transifex-config

@@ -1,7 +1,7 @@
 #!/usr/bin/env python
 # -*- coding: utf-8 -*-
 '''
-    :codeauthor: :email:`Pedro Algarvio (pedro@algarvio.me)`
+    :codeauthor: Pedro Algarvio (pedro@algarvio.me)
 
 
     setup-transifex-config

doc/.scripts/update-transifex-source-translations

@@ -1,7 +1,7 @@
 #!/usr/bin/env python
 # -*- coding: utf-8 -*-
 '''
-    :codeauthor: :email:`Pedro Algarvio (pedro@algarvio.me)`
+    :codeauthor: Pedro Algarvio (pedro@algarvio.me)
 
 
     update-transifex-source-translations

doc/_ext/saltautodoc.py

@@ -1,6 +1,6 @@
 # -*- coding: utf-8 -*-
 '''
-    :codeauthor: :email:`Pedro Algarvio (pedro@algarvio.me)`
+    :codeauthor: Pedro Algarvio (pedro@algarvio.me)
 
 
     saltautodoc.py

doc/conf.py

@@ -6,6 +6,7 @@ Sphinx documentation for Salt
 import functools
 import sys
 import os
+import re
 import types
 import time
 
@@ -106,6 +107,7 @@ MOCK_MODULES = [
 
     'tornado',
     'tornado.concurrent',
+    'tornado.escape',
     'tornado.gen',
     'tornado.httpclient',
     'tornado.httpserver',
@@ -127,53 +129,56 @@ MOCK_MODULES = [
     # modules, renderers, states, returners, et al
     'ClusterShell',
     'ClusterShell.NodeSet',
-    'django',
-    'libvirt',
     'MySQLdb',
     'MySQLdb.cursors',
-    'nagios_json',
-    'psutil',
-    'pycassa',
-    'pymongo',
-    'rabbitmq_server',
-    'redis',
-    'requests',
-    'requests.exceptions',
-    'rpm',
-    'rpmUtils',
-    'rpmUtils.arch',
-    'yum',
     'OpenSSL',
-    'zfs',
-    'salt.ext.six.moves.winreg',
-    'win32security',
-    'ntsecuritycon',
-    'napalm',
+    'avahi',
+    'boto.regioninfo',
+    'concurrent',
+    'dbus',
+    'django',
+    'dns',
+    'dns.resolver',
     'dson',
+    'hjson',
     'jnpr',
-    'json',
-    'lxml',
-    'lxml.etree',
     'jnpr.junos',
     'jnpr.junos.utils',
     'jnpr.junos.utils.config',
     'jnpr.junos.utils.sw',
-    'dns',
-    'dns.resolver',
+    'json',
     'keyring',
+    'libvirt',
+    'lxml',
+    'lxml.etree',
+    'msgpack',
+    'nagios_json',
+    'napalm',
     'netaddr',
     'netaddr.IPAddress',
     'netaddr.core',
     'netaddr.core.AddrFormatError',
+    'ntsecuritycon',
+    'psutil',
+    'pycassa',
+    'pyconnman',
+    'pyiface',
+    'pymongo',
     'pyroute2',
     'pyroute2.ipdb',
-    'avahi',
-    'dbus',
+    'rabbitmq_server',
+    'redis',
+    'rpm',
+    'rpmUtils',
+    'rpmUtils.arch',
+    'salt.ext.six.moves.winreg',
     'twisted',
     'twisted.internet',
     'twisted.internet.protocol',
     'twisted.internet.protocol.DatagramProtocol',
-    'msgpack',
+    'win32security',
+    'yum',
+    'zfs',
 ]
 
 for mod_name in MOCK_MODULES:
@@ -210,6 +215,8 @@ sys.modules['ntsecuritycon'].SYNCHRONIZE = 0
 
 # Define a fake version attribute for the following libs.
 sys.modules['cherrypy'].config = mock_decorator_with_params
+sys.modules['tornado'].version_info = (0, 0, 0)
+sys.modules['boto.regioninfo']._load_json_file = {'endpoints': None}
 
 
 # -- Add paths to PYTHONPATH ---------------------------------------------------
@@ -237,8 +244,7 @@ formulas_dir = os.path.join(os.pardir, docs_basepath, 'formulas')
 
 # ----- Intersphinx Settings ------------------------------------------------>
 intersphinx_mapping = {
-        'python2': ('http://docs.python.org/2', None),
-        'python3': ('http://docs.python.org/3', None)
+    'python': ('https://docs.python.org/3', None)
 }
 # <---- Intersphinx Settings -------------------------------------------------
 
@@ -250,8 +256,8 @@ on_saltstack = 'SALT_ON_SALTSTACK' in os.environ
 project = 'Salt'
 
 version = salt.version.__version__
-latest_release = '2018.3.0'  # latest release
-previous_release = '2017.7.5'  # latest release from previous branch
+latest_release = '2018.3.2'  # latest release
+previous_release = '2017.7.7'  # latest release from previous branch
 previous_release_dir = '2017.7'  # path on web server for previous branch
 next_release = ''  # next release
 next_release_dir = ''  # path on web server for next release branch
@@ -316,6 +322,9 @@ modindex_common_prefix = ['salt.']
 
 autosummary_generate = True
 
+# strip git rev as there won't necessarily be a release based on it
+stripped_release = re.sub(r'-\d+-g[0-9a-f]+$', '', release)
+
 # Define a substitution for linking to the latest release tarball
 rst_prolog = """\
 .. |current_release_doc| replace:: :doc:`/topics/releases/{release}`
@@ -352,14 +361,13 @@ rst_prolog = """\
      <p>x86_64: <a href="https://repo.saltstack.com/osx/salt-{release}-py3-x86_64.pkg"><strong>salt-{release}-py3-x86_64.pkg</strong></a>
       | <a href="https://repo.saltstack.com/osx/salt-{release}-py3-x86_64.pkg.md5"><strong>md5</strong></a></p>
 
-""".format(release=release)
+""".format(release=stripped_release)
 
 # A shortcut for linking to tickets on the GitHub issue tracker
 extlinks = {
     'blob': ('https://github.com/saltstack/salt/blob/%s/%%s' % 'develop', None),
-    'download': ('https://cloud.github.com/downloads/saltstack/salt/%s', None),
-    'issue': ('https://github.com/saltstack/salt/issues/%s', 'issue '),
-    'pull': ('https://github.com/saltstack/salt/pull/%s', 'PR '),
+    'issue': ('https://github.com/saltstack/salt/issues/%s', 'issue #'),
+    'pull': ('https://github.com/saltstack/salt/pull/%s', 'PR #'),
     'formula_url': ('https://github.com/saltstack-formulas/%s', ''),
 }
 

doc/contents.rst

@@ -7,6 +7,7 @@ Salt Table of Contents
 .. toctree::
     :maxdepth: 2
 
+    topics/index
     topics/installation/index
     topics/configuration/index
     topics/using_salt
@@ -15,12 +16,16 @@ Salt Table of Contents
     topics/utils/index
     topics/event/index
     topics/orchestrate/index
+    topics/solaris/index
     topics/ssh/index
+    topics/thorium/index
     topics/cloud/index
     topics/proxyminion/index
     topics/network_automation/index
     topics/virt/index
     ref/cli/index
+    ref/pillar/index
+    ref/tops/index
     ref/index
     topics/api
     topics/topology/index
@@ -30,3 +35,4 @@ Salt Table of Contents
     topics/development/index
     topics/releases/index
     topics/venafi/index
+    glossary

doc/faq.rst

@@ -148,22 +148,23 @@ Why aren't my custom modules/states/etc. available on my Minions?
 -----------------------------------------------------------------
 
 Custom modules are synced to Minions when
-:mod:`saltutil.sync_modules <salt.modules.saltutil.sync_modules>`,
-or :mod:`saltutil.sync_all <salt.modules.saltutil.sync_all>` is run.
-Custom modules are also synced by :mod:`state.apply` when run without
-any arguments.
+:py:func:`saltutil.sync_modules <salt.modules.saltutil.sync_modules>`,
+or :py:func:`saltutil.sync_all <salt.modules.saltutil.sync_all>` is run.
 
+Similarly, custom states are synced to Minions when :py:func:`saltutil.sync_states
+<salt.modules.saltutil.sync_states>`, or :py:func:`saltutil.sync_all
+<salt.modules.saltutil.sync_all>` is run.
 
-Similarly, custom states are synced to Minions
-when :mod:`state.apply <salt.modules.state.apply_>`,
-:mod:`saltutil.sync_states <salt.modules.saltutil.sync_states>`, or
-:mod:`saltutil.sync_all <salt.modules.saltutil.sync_all>` is run.
+They are both also synced when a :ref:`highstate <running-highstate>` is
+triggered.
 
-Custom states are also synced by :mod:`state.apply<salt.modules.state.apply_>`
-when run without any arguments.
+As of the Fluorine release, as well as 2017.7.7 and 2018.3.2 in their
+respective release cycles, the ``sync`` argument to :py:func:`state.apply
+<salt.modules.state.apply_>`/:py:func:`state.sls <salt.modules.state.sls>` can
+be used to sync custom types when running individual SLS files.
 
 Other custom types (renderers, outputters, etc.) have similar behavior, see the
-documentation for the :mod:`saltutil <salt.modules.saltutil>` module for more
+documentation for the :py:func:`saltutil <salt.modules.saltutil>` module for more
 information.
 
 :ref:`This reactor example <minion-start-reactor>` can be used to automatically

doc/man/salt-api.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-API" "1" "May 09, 2018" "2018.3.1" "Salt"
+.TH "SALT-API" "1" "Jun 14, 2018" "2018.3.2" "Salt"
 .SH NAME
 salt-api \- salt-api Command
 .

doc/man/salt-call.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-CALL" "1" "May 09, 2018" "2018.3.1" "Salt"
+.TH "SALT-CALL" "1" "Jun 14, 2018" "2018.3.2" "Salt"
 .SH NAME
 salt-call \- salt-call Documentation
 .

doc/man/salt-cloud.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-CLOUD" "1" "May 09, 2018" "2018.3.1" "Salt"
+.TH "SALT-CLOUD" "1" "Jun 14, 2018" "2018.3.2" "Salt"
 .SH NAME
 salt-cloud \- Salt Cloud Command
 .

doc/man/salt-cp.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-CP" "1" "May 09, 2018" "2018.3.1" "Salt"
+.TH "SALT-CP" "1" "Jun 14, 2018" "2018.3.2" "Salt"
 .SH NAME
 salt-cp \- salt-cp Documentation
 .

doc/man/salt-key.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-KEY" "1" "May 09, 2018" "2018.3.1" "Salt"
+.TH "SALT-KEY" "1" "Jun 14, 2018" "2018.3.2" "Salt"
 .SH NAME
 salt-key \- salt-key Documentation
 .

doc/man/salt-master.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-MASTER" "1" "May 09, 2018" "2018.3.1" "Salt"
+.TH "SALT-MASTER" "1" "Jun 14, 2018" "2018.3.2" "Salt"
 .SH NAME
 salt-master \- salt-master Documentation
 .

doc/man/salt-minion.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-MINION" "1" "May 09, 2018" "2018.3.1" "Salt"
+.TH "SALT-MINION" "1" "Jun 14, 2018" "2018.3.2" "Salt"
 .SH NAME
 salt-minion \- salt-minion Documentation
 .

doc/man/salt-proxy.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-PROXY" "1" "May 09, 2018" "2018.3.1" "Salt"
+.TH "SALT-PROXY" "1" "Jun 14, 2018" "2018.3.2" "Salt"
 .SH NAME
 salt-proxy \- salt-proxy Documentation
 .

doc/man/salt-run.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-RUN" "1" "May 09, 2018" "2018.3.1" "Salt"
+.TH "SALT-RUN" "1" "Jun 14, 2018" "2018.3.2" "Salt"
 .SH NAME
 salt-run \- salt-run Documentation
 .

doc/man/salt-ssh.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-SSH" "1" "May 09, 2018" "2018.3.1" "Salt"
+.TH "SALT-SSH" "1" "Jun 14, 2018" "2018.3.2" "Salt"
 .SH NAME
 salt-ssh \- salt-ssh Documentation
 .

doc/man/salt-syndic.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-SYNDIC" "1" "May 09, 2018" "2018.3.1" "Salt"
+.TH "SALT-SYNDIC" "1" "Jun 14, 2018" "2018.3.2" "Salt"
 .SH NAME
 salt-syndic \- salt-syndic Documentation
 .

doc/man/salt-unity.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-UNITY" "1" "May 09, 2018" "2018.3.1" "Salt"
+.TH "SALT-UNITY" "1" "Jun 14, 2018" "2018.3.2" "Salt"
 .SH NAME
 salt-unity \- salt-unity Command
 .

doc/man/salt.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT" "1" "May 09, 2018" "2018.3.1" "Salt"
+.TH "SALT" "1" "Jun 14, 2018" "2018.3.2" "Salt"
 .SH NAME
 salt \- salt
 .

doc/man/spm.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SPM" "1" "May 09, 2018" "2018.3.1" "Salt"
+.TH "SPM" "1" "Jun 14, 2018" "2018.3.2" "Salt"
 .SH NAME
 spm \- Salt Package Manager Command
 .

doc/ref/beacons/all/salt.beacons.sensehat.rst

@@ -1,5 +1,5 @@
 salt.beacons.sensehat module
-=======================
+============================
 
 .. automodule:: salt.beacons.sensehat
     :members:

doc/ref/cache/all/index.rst

@@ -1,7 +1,7 @@
 .. _all-salt.cache:
 
 =============
-cache modules
+Cache Modules
 =============
 
 .. currentmodule:: salt.cache
@@ -10,6 +10,8 @@ cache modules
     :toctree:
     :template: autosummary.rst.tmpl
 
-    localfs
     consul
+    etcd_cache
+    localfs
+    mysql_cache
     redis_cache

doc/ref/cache/all/salt.cache.consul.rst

@@ -1,5 +1,5 @@
-salt.cache.consul module
-========================
+salt.cache.consul
+=================
 
 .. automodule:: salt.cache.consul
     :members:

doc/ref/cache/all/salt.cache.etcd_cache.rst

@@ -1,5 +1,5 @@
-salt.cache.etcd_cache module
-=============================
+salt.cache.etcd_cache
+=====================
 
 .. automodule:: salt.cache.etcd_cache
     :members:

doc/ref/cache/all/salt.cache.localfs.rst

@@ -1,5 +1,5 @@
-salt.cache.localfs module
-=========================
+salt.cache.localfs
+==================
 
 .. automodule:: salt.cache.localfs
     :members:

doc/ref/cache/all/salt.cache.mysql_cache.rst

@@ -1,5 +1,5 @@
-salt.cache.mysql_cache module
-=============================
+salt.cache.mysql_cache
+======================
 
 .. automodule:: salt.cache.mysql_cache
     :members:

doc/ref/cache/all/salt.cache.redis_cache.rst

@@ -1,5 +1,5 @@
-salt.cache.redis_cache module
-=============================
+salt.cache.redis_cache
+======================
 
 .. automodule:: salt.cache.redis_cache
     :members:

doc/ref/cli/index.rst

@@ -74,6 +74,12 @@ salt-syndic
 
     salt-syndic
 
+salt-unity
+==========
+.. toctree::
+
+    salt-unity
+
 salt-api
 ========
 .. toctree::

doc/ref/cli/salt-ssh.rst

@@ -112,6 +112,10 @@ Authentication Options
 
     Specify the SSH private key file to be used for authentication.
 
+.. option:: --priv-passwd=SSH_PRIV_PASSWD
+
+    Specify the SSH private key file's passphrase if need be.
+
 .. option:: -i, --ignore-host-keys
 
     By default ssh host keys are honored and connections  will ask for

doc/ref/cli/salt.rst

@@ -46,14 +46,6 @@ Options
     Instead of waiting for the job to run on minions only print the job id of
     the started execution and complete.
 
-.. option:: --state-output=STATE_OUTPUT
-
-    .. versionadded:: 0.17
-
-    Override the configured ``state_output`` value for minion output. One of
-    ``full``, ``terse``, ``mixed``, ``changes`` or ``filter``.  Default:
-    ``full``.
-
 .. option:: --subset=SUBSET
 
     Execute the routine on a random subset of the targeted minions.  The

doc/ref/clients/index.rst

@@ -72,6 +72,7 @@ Each module type has a corresponding loader function.
 Salt's Client Interfaces
 ========================
 
+.. _client-interfaces:
 .. _local-client:
 
 LocalClient

doc/ref/clouds/all/index.rst

@@ -23,6 +23,7 @@ cloud modules
     lxc
     msazure
     nova
+    oneandone
     opennebula
     openstack
     parallels

doc/ref/clouds/all/salt.cloud.clouds.aliyun.rst

@@ -1,6 +1,6 @@
-===============================
+========================
 salt.cloud.clouds.aliyun
-===============================
+========================
 
 .. automodule:: salt.cloud.clouds.aliyun
     :members:

doc/ref/clouds/all/salt.cloud.clouds.vultrpy.rst

@@ -1,5 +1,6 @@
-salt.cloud.clouds.vultrpy module
-================================
+=========================
+salt.cloud.clouds.vultrpy
+=========================
 
 .. automodule:: salt.cloud.clouds.vultrpy
     :members:

doc/ref/configuration/logging/index.rst

@@ -9,7 +9,7 @@ issues you might find along the way.
 
 If you want to get some more information on the nitty-gritty of salt's logging
 system, please head over to the :ref:`logging development
-document<logging-internals>`, if all you're after is salt's logging
+document <logging-internals>`, if all you're after is salt's logging
 configurations, please continue reading.
 
 
@@ -25,10 +25,9 @@ example, setting ``log_level: error`` will log statements at ``error``,
 ``quiet`` level.
 
 Most of the logging levels are defined by default in Python's logging library
-and can be found in the official `Python documentation
-<https://docs.python.org/library/logging.html#levels>`_.  Salt uses some more
-levels in addition to the standard levels.  All levels available in salt are
-shown in the table below.
+and can be found in the official :ref:`Python documentation <python:levels>`.
+Salt uses some more levels in addition to the standard levels.  All levels
+available in salt are shown in the table below.
 
 .. note::
 
@@ -74,11 +73,14 @@ The log records can be sent to a regular file, local path name, or network
 location.  Remote logging works best when configured to use rsyslogd(8) (e.g.:
 ``file:///dev/log``), with rsyslogd(8) configured for network logging.  The
 format for remote addresses is:
-``<file|udp|tcp>://<host|socketpath>:<port-if-required>/<log-facility>``. Where
-``log-facility`` is the symbolic name of a syslog facility as defined in the
-:ref:`SysLogHandler documentation
-<python2:logging.handlers.SysLogHandler.encodePriority>` . It defaults to
-``LOG_USER``.
+
+.. code-block:: text
+
+    <file|udp|tcp>://<host|socketpath>:<port-if-required>/<log-facility>
+
+Where ``log-facility`` is the symbolic name of a syslog facility as defined in
+the :py:meth:`SysLogHandler documentation
+<logging.handlers.SysLogHandler.encodePriority>`. It defaults to ``LOG_USER``.
 
 Default: Dependent of the binary being executed, for example, for
 ``salt-master``, ``/var/log/salt/master``.
@@ -148,7 +150,7 @@ The level of messages to send to the log file. One of ``all``, ``garbage``,
 Default: ``%H:%M:%S``
 
 The date and time format used in console log messages. Allowed date/time
-formatting can be seen on :func:`time.strftime <python2:time.strftime>`.
+formatting matches those used in :py:func:`time.strftime`.
 
 .. code-block:: yaml
 
@@ -162,7 +164,7 @@ formatting can be seen on :func:`time.strftime <python2:time.strftime>`.
 Default: ``%Y-%m-%d %H:%M:%S``
 
 The date and time format used in log file messages. Allowed date/time
-formatting can be seen on :func:`time.strftime <python2:time.strftime>`.
+formatting matches those used in :py:func:`time.strftime`.
 
 .. code-block:: yaml
 
@@ -176,8 +178,8 @@ formatting can be seen on :func:`time.strftime <python2:time.strftime>`.
 Default: ``[%(levelname)-8s] %(message)s``
 
 The format of the console logging messages. All standard python logging
-:ref:`LogRecord attributes <python2:logrecord-attributes>` can be used.  Salt
-also provides these custom LogRecord attributes to colorize console log output:
+:py:class:`~logging.LogRecord` attributes can be used. Salt also provides these
+custom LogRecord attributes to colorize console log output:
 
 .. code-block:: python
 
@@ -204,9 +206,9 @@ also provides these custom LogRecord attributes to colorize console log output:
 Default: ``%(asctime)s,%(msecs)03d [%(name)-17s][%(levelname)-8s] %(message)s``
 
 The format of the log file logging messages. All standard python logging
-:ref:`LogRecord attributes <python2:logrecord-attributes>` can be used.  Salt
-also provides these custom LogRecord attributes that include padding and
-enclosing brackets ``[`` and ``]``:
+:py:class:`~logging.LogRecord` attributes can be used.  Salt also provides
+these custom LogRecord attributes that include padding and enclosing brackets
+``[`` and ``]``:
 
 .. code-block:: python
 

doc/ref/configuration/master.rst

@@ -428,7 +428,7 @@ to False.
 .. conf_master:: color_theme
 
 ``color_theme``
----------
+---------------
 
 Default: ``""``
 
@@ -728,31 +728,6 @@ master event bus. The value is expressed in bytes.
 
     max_event_size: 1048576
 
-.. conf_master:: ping_on_rotate
-
-``ping_on_rotate``
-------------------
-
-.. versionadded:: 2014.7.0
-
-Default:  ``False``
-
-By default, the master AES key rotates every 24 hours. The next command
-following a key rotation will trigger a key refresh from the minion which may
-result in minions which do not respond to the first command after a key refresh.
-
-To tell the master to ping all minions immediately after an AES key refresh, set
-ping_on_rotate to ``True``. This should mitigate the issue where a minion does not
-appear to initially respond after a key is rotated.
-
-Note that ping_on_rotate may cause high load on the master immediately after
-the key rotation event as minions reconnect. Consider this carefully if this
-salt master is managing a large number of minions.
-
-.. code-block:: yaml
-
-    ping_on_rotate: False
-
 .. conf_master:: master_job_cache
 
 ``master_job_cache``
@@ -828,8 +803,7 @@ Causes the master to periodically look for actively connected minions.
 :ref:`Presence events <event-master_presence>` are fired on the event bus on a
 regular interval with a list of connected minions, as well as events with lists
 of newly connected or disconnected minions. This is a master-only operation
-that does not send executions to minions. Note, this does not detect minions
-that connect to a master via localhost.
+that does not send executions to minions.
 
 .. code-block:: yaml
 
@@ -840,6 +814,8 @@ that connect to a master via localhost.
 ``ping_on_rotate``
 ------------------
 
+.. versionadded:: 2014.7.0
+
 Default: ``False``
 
 By default, the master AES key rotates every 24 hours. The next command
@@ -850,9 +826,9 @@ To tell the master to ping all minions immediately after an AES key refresh,
 set ``ping_on_rotate`` to ``True``. This should mitigate the issue where a
 minion does not appear to initially respond after a key is rotated.
 
-Note that ping_on_rotate may cause high load on the master immediately after
-the key rotation event as minions reconnect. Consider this carefully if this
-salt master is managing a large number of minions.
+Note that enabling this may cause high load on the master immediately after the
+key rotation event as minions reconnect. Consider this carefully if this salt
+master is managing a large number of minions.
 
 If disabled, it is recommended to handle this event by listening for the
 ``aes_key_rotate`` event with the ``key`` tag and acting appropriately.
@@ -872,8 +848,7 @@ Changes the underlying transport layer. ZeroMQ is the recommended transport
 while additional transport layers are under development. Supported values are
 ``zeromq``, ``raet`` (experimental), and ``tcp`` (experimental). This setting has
 a significant impact on performance and should not be changed unless you know
-what you are doing! Transports are explained in :ref:`Salt Transports
-<transports>`.
+what you are doing!
 
 .. code-block:: yaml
 
@@ -886,10 +861,10 @@ what you are doing! Transports are explained in :ref:`Salt Transports
 
 Default: ``{}``
 
-(experimental) Starts multiple transports and overrides options for each transport with the provided dictionary
-This setting has a significant impact on performance and should not be changed unless you know
-what you are doing! Transports are explained in :ref:`Salt Transports
-<transports>`. The following example shows how to start a TCP transport alongside a ZMQ transport.
+(experimental) Starts multiple transports and overrides options for each
+transport with the provided dictionary This setting has a significant impact on
+performance and should not be changed unless you know what you are doing!  The
+following example shows how to start a TCP transport alongside a ZMQ transport.
 
 .. code-block:: yaml
 
@@ -1031,7 +1006,7 @@ a minion performs an authentication check with the master.
 .. conf_master:: minion_data_cache_events
 
 ``minion_data_cache_events``
---------------------
+----------------------------
 
 .. versionadded:: 2017.7.3
 
@@ -1096,6 +1071,23 @@ Define the default salt-ssh roster module to use
 
     roster: cache
 
+.. conf_master:: roster_defaults
+
+``roster_defaults``
+-------------------
+
+.. versionadded:: 2017.7.0
+
+Default settings which will be inherited by all rosters.
+
+.. code-block:: yaml
+
+    roster_defaults:
+      user: daniel
+      sudo: True
+      priv: /root/.ssh/id_rsa
+      tty: True
+
 .. conf_master:: roster_file
 
 ``roster_file``
@@ -1103,24 +1095,27 @@ Define the default salt-ssh roster module to use
 
 Default: ``/etc/salt/roster``
 
-Pass in an alternative location for the salt-ssh `flat` roster file.
+Pass in an alternative location for the salt-ssh :py:mod:`flat
+<salt.roster.flat>` roster file.
 
 .. code-block:: yaml
 
     roster_file: /root/roster
 
-.. conf_master:: roster_file
+.. conf_master:: rosters
 
 ``rosters``
----------------
+-----------
 
-Default: None
+Default: ``None``
 
-Define locations for `flat` roster files so they can be chosen when using Salt API.
-An administrator can place roster files into these locations.
-Then when calling Salt API, parameter 'roster_file' should contain a relative path to these locations.
-That is, "roster_file=/foo/roster" will be resolved as "/etc/salt/roster.d/foo/roster" etc.
-This feature prevents passing insecure custom rosters through the Salt API.
+Define locations for :py:mod:`flat <salt.roster.flat>` roster files so they can
+be chosen when using Salt API. An administrator can place roster files into
+these locations. Then, when calling Salt API, the :conf_master:`roster_file`
+parameter should contain a relative path to these locations. That is,
+``roster_file=/foo/roster`` will be resolved as
+``/etc/salt/roster.d/foo/roster`` etc. This feature prevents passing insecure
+custom rosters through the Salt API.
 
 .. code-block:: yaml
 
@@ -1141,6 +1136,19 @@ The ssh password to log in with.
 
     ssh_passwd: ''
 
+.. conf_master:: ssh_priv_passwd
+
+``ssh_priv_passwd``
+-------------------
+
+Default: ``''``
+
+Passphrase for ssh private key file.
+
+.. code-block:: yaml
+
+    ssh_priv_passwd: ''
+
 .. conf_master:: ssh_port
 
 ``ssh_port``
@@ -1740,10 +1748,10 @@ constant names without ssl module prefix: ``CERT_REQUIRED`` or ``PROTOCOL_SSLv23
         certfile: <path_to_certfile>
         ssl_version: PROTOCOL_TLSv1_2
 
-.. conf_master:: allow_minion_key_revoke
+.. conf_master:: preserve_minion_cache
 
-``allow_minion_key_revoke``
----------------------------
+``preserve_minion_cache``
+-------------------------
 
 Default: ``False``
 
@@ -1772,7 +1780,7 @@ the master will drop the request and the minion's key will remain accepted.
 
 .. code-block:: yaml
 
-    rotate_aes_key: True
+    allow_minion_key_revoke: False
 
 
 Master Large Scale Tuning Settings
@@ -2197,6 +2205,7 @@ Example using line statements and line comments to increase ease of use:
 If your configuration options are
 
 .. code-block:: yaml
+
     jinja_sls_env:
       line_statement_prefix: '%'
       line_comment_prefix: '##'
@@ -2206,7 +2215,7 @@ as a jinja statement and will interpret anything after a ``##`` as a comment.
 
 This allows the following more convenient syntax to be used:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     ## (this comment will not stay once rendered)
     # (this comment remains in the rendered template)
@@ -2220,7 +2229,7 @@ This allows the following more convenient syntax to be used:
 The following less convenient but equivalent syntax would have to
 be used if you had not set the line_statement and line_comment options:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {# (this comment will not stay once rendered) #}
     # (this comment remains in the rendered template)
@@ -4354,7 +4363,7 @@ Default: ``['+refs/heads/*:refs/remotes/origin/*', '+refs/tags/*:refs/tags/*']``
 When fetching from remote repositories, by default Salt will fetch branches and
 tags. This parameter can be used to override the default and specify
 alternate refspecs to be fetched. This parameter works similarly to its
-:ref:`GitFS counterpart <git_pillar-custom-refspecs>`, in that it can be
+:ref:`GitFS counterpart <gitfs-custom-refspecs>`, in that it can be
 configured both globally and for individual remotes.
 
 .. code-block:: yaml
@@ -4402,12 +4411,14 @@ The pillar_source_merging_strategy option allows you to configure merging
 strategy between different sources. It accepts 5 values:
 
 * ``none``:
-.. versionadded:: 2016.3.4
+
   It will not do any merging at all and only parse the pillar data from the passed environment and 'base' if no environment was specified.
 
+  .. versionadded:: 2016.3.4
+
 * ``recurse``:
 
-  it will merge recursively mapping of data. For example, theses 2 sources:
+  It will recursively merge data. For example, theses 2 sources:
 
   .. code-block:: yaml
 
@@ -5509,7 +5520,7 @@ Default: ``['+refs/heads/*:refs/remotes/origin/*', '+refs/tags/*:refs/tags/*']``
 When fetching from remote repositories, by default Salt will fetch branches and
 tags. This parameter can be used to override the default and specify
 alternate refspecs to be fetched. This parameter works similarly to its
-:ref:`GitFS counterpart <winrepo-custom-refspecs>`, in that it can be
+:ref:`GitFS counterpart <gitfs-custom-refspecs>`, in that it can be
 configured both globally and for individual remotes.
 
 .. code-block:: yaml

doc/ref/configuration/minion.rst

@@ -346,7 +346,7 @@ option on the Salt master.
 .. conf_minion:: publish_port
 
 ``publish_port``
----------------
+----------------
 
 Default: ``4505``
 
@@ -583,7 +583,7 @@ ids.
 
 Default: ``True``
 
-Caches the minion id to a file when the minion's :minion_conf:`id` is not
+Caches the minion id to a file when the minion's :conf_minion:`id` is not
 statically defined in the minion config. This setting prevents potential
 problems when automatic minion id resolution changes, which can cause the
 minion to lose connection with the master. To turn off minion id caching,
@@ -645,7 +645,7 @@ This directory may contain sensitive data and should be protected accordingly.
 .. conf_master:: color_theme
 
 ``color_theme``
----------
+---------------
 
 Default: ``""``
 
@@ -1029,7 +1029,7 @@ is appropriate if you expect occasional downtime from the master(s).
 
     master_tries: 1
 
-.. conf_minion:: acceptance_wait_time_max
+.. conf_minion:: auth_tries
 
 ``auth_tries``
 --------------
@@ -1297,8 +1297,7 @@ Changes the underlying transport layer. ZeroMQ is the recommended transport
 while additional transport layers are under development. Supported values are
 ``zeromq``, ``raet`` (experimental), and ``tcp`` (experimental). This setting has
 a significant impact on performance and should not be changed unless you know
-what you are doing! Transports are explained in :ref:`Salt Transports
-<transports>`.
+what you are doing!
 
 .. code-block:: yaml
 
@@ -1404,6 +1403,58 @@ The password used for HTTP proxy access.
 
     proxy_password: obolus
 
+.. conf_minion:: no_proxy
+
+``no_proxy``
+------------
+
+.. versionadded:: Fluorine
+
+Default: ``[]``
+
+List of hosts to bypass HTTP proxy
+
+.. note::
+    This key does nothing unless proxy_host etc is configured, it does not
+    support any kind of wildcards.
+
+.. code-block:: yaml
+
+    no_proxy: [ '127.0.0.1', 'foo.tld' ]
+
+Docker Configuration
+====================
+
+.. conf_minion:: docker.update_mine
+
+``docker.update_mine``
+----------------------
+
+.. versionadded:: 2017.7.8,2018.3.3
+.. versionchanged:: Fluorine
+    The default value is now ``False``
+
+Default: ``True``
+
+If enabled, when containers are added, removed, stopped, started, etc., the
+:ref:`mine <salt-mine>` will be updated with the results of :py:func:`docker.ps
+verbose=True all=True host=True <salt.modules.dockermod.ps>`. This mine data is
+used by :py:func:`mine.get_docker <salt.modules.mine.get_docker>`. Set this
+option to ``False`` to keep Salt from updating the mine with this information.
+
+.. note::
+    This option can also be set in Grains or Pillar data, with Grains
+    overriding Pillar and the minion config file overriding Grains.
+
+.. note::
+    Disabling this will of course keep :py:func:`mine.get_docker
+    <salt.modules.mine.get_docker>` from returning any information for a given
+    minion.
+
+.. code-block:: yaml
+
+    docker.update_mine: False
+
 .. conf_minion:: docker.compare_container_networks
 
 ``docker.compare_container_networks``
@@ -1438,6 +1489,7 @@ Specifies which keys are examined by
         - GlobalIPv6Address
         - IPv6Gateway
 
+
 Minion Execution Module Management
 ==================================
 
@@ -1647,7 +1699,7 @@ below.
 Default: ``-1``
 
 Specify a max size (in bytes) for modules on import. This feature is currently
-only supported on *nix operating systems and requires psutil.
+only supported on \*NIX operating systems and requires psutil.
 
 .. code-block:: yaml
 
@@ -2714,7 +2766,7 @@ Thread Settings
 .. conf_minion:: multiprocessing
 
 ``multiprocessing``
--------
+-------------------
 
 Default: ``True``
 
@@ -2731,7 +2783,7 @@ executed in a thread.
 .. conf_minion:: process_count_max
 
 ``process_count_max``
--------
+---------------------
 
 .. versionadded:: 2018.3.0
 

doc/ref/engines/all/salt.engines.napalm_syslog.rst

@@ -1,6 +1,6 @@
-===========================
+==========================
 salt.engines.napalm_syslog
-===========================
+==========================
 
 .. automodule:: salt.engines.napalm_syslog
     :members:

doc/ref/executors/all/index.rst

@@ -11,5 +11,6 @@ executors modules
     :template: autosummary.rst.tmpl
 
     direct_call
+    docker
     splay
     sudo

doc/ref/executors/all/salt.executors.docker.rst

@@ -0,0 +1,6 @@
+salt.executors.docker module
+============================
+
+.. automodule:: salt.executors.docker
+    :members:
+

doc/ref/executors/index.rst

@@ -83,3 +83,7 @@ option set by commandline or API ``data.get('executor_opts',
 {}).get('splaytime')`` should be used. So if an option is safe and must be
 accessible by user executor should check it in both places, but if an option is
 unsafe it should be read from the only config ignoring the passed request data.
+
+There is also a function named ``all_missing_func`` which the name of the
+``func`` is passed, which can be used to verify if the command should still be
+run, even if it is not loaded in minion_mods.

doc/ref/grains/all/salt.grains.metadata.rst

@@ -1,6 +1,6 @@
-=================
+====================
 salt.grains.metadata
-=================
+====================
 
 .. automodule:: salt.grains.metadata
     :members:

doc/ref/internals/unicode.rst

@@ -1,4 +1,4 @@
-.. __unicode:
+.. _unicode:
 
 ===============
 Unicode in Salt
@@ -12,19 +12,29 @@ several basic rules to help developers handle Unicode correctly.
 
 Salt's basic workflow for Unicode handling is as follows:
 
-1) Salt should convert whatever data is passed on CLI/API to Unicode. Internally,
-everything that Salt does should be Unicode unless it is printing to the screen
-or writing to storage.
+1) Salt should convert whatever data is passed on CLI/API to Unicode.
+   Internally, everything that Salt does should be Unicode unless it is
+   printing to the screen or writing to storage.
 
 2) Modules and various Salt pluggable systems use incoming data assuming Unicode.
 
-    2.1) For Salt modules that query an API; the module should convert the data received from the API into Unicode.
+   2.1) For Salt modules that query an API; the module should convert the data
+        received from the API into Unicode.
 
-    2.2) For Salt modules that shell out to get output; the module should convert data received into Unicode. (This does not apply if using the `cmd` execution module, which should handle this for you.
+   2.2) For Salt modules that shell out to get output; the module should
+        convert data received into Unicode. (This does not apply if using the
+        :mod:`cmd <salt.modules.cmdmod>` execution module, which should handle
+        this for you.
 
-    2.3) For Salt modules which print directly to the console (not via an outputter) or which write directly to disk, a string should be encoded when appropriate. To handle this conversion, the global variable `__salt_system_encoding__` is available, which declares the locale of the system that Salt is running on.
+   2.3) For Salt modules which print directly to the console (not via an
+        outputter) or which write directly to disk, a string should be encoded
+        when appropriate. To handle this conversion, the global variable
+        ``__salt_system_encoding__`` is available, which declares the locale of
+        the system that Salt is running on.
 
-3) When a function in a Salt module returns, it should return Unicode.
+3) When a function in a Salt module returns a string, it should return a
+   ``unicode`` type in Python 2.
 
-4) When Salt delivers the data to an outputter or a returner, it is the job of the outputter
-or returner to encode the Unicode before displaying it on the console or writing it to storage.
+4) When Salt delivers the data to an outputter or a returner, it is the job of
+   the outputter or returner to encode the Unicode before displaying it on the
+   console or writing it to storage.

doc/ref/modules/all/index.rst

@@ -11,6 +11,8 @@ execution modules
         salt.modules.group
         salt.modules.kernelpkg
         salt.modules.pkg
+        salt.modules.service
+        salt.modules.shadow
         salt.modules.user
 
 .. currentmodule:: salt.modules
@@ -96,7 +98,6 @@ execution modules
     cron
     csf
     cyg
-    cytest
     daemontools
     data
     datadog_api
@@ -282,6 +283,7 @@ execution modules
     netbox
     netbsd_sysctl
     netbsdservice
+    netmiko_mod
     netscaler
     network
     neutron
@@ -371,6 +373,7 @@ execution modules
     s3
     s6
     salt_proxy
+    saltcheck
     saltcloudmod
     saltutil
     schedule
@@ -425,6 +428,7 @@ execution modules
     system
     system_profiler
     systemd
+    template
     telegram
     telemetry
     temp
@@ -485,7 +489,6 @@ execution modules
     win_system
     win_task
     win_timezone
-    win_update
     win_useradd
     win_wua
     x509
@@ -502,5 +505,6 @@ execution modules
     znc
     zoneadm
     zonecfg
+    zookeeper
     zpool
     zypper

doc/ref/modules/all/salt.modules.cytest.rst

@@ -1,5 +0,0 @@
-salt.modules.cytest module
-==========================
-
-.. automodule:: salt.modules.cytest
-    :members:

doc/ref/modules/all/salt.modules.libcloud_storage.rst

@@ -1,5 +1,5 @@
-salt.modules.libcloud_storage module
-================================
+salt.modules.libcloud_storage
+=============================
 
 .. automodule:: salt.modules.libcloud_storage
     :members:

doc/ref/modules/all/salt.modules.napalm_network.rst

@@ -1,5 +1,5 @@
 salt.modules.napalm_network module
-===============================
+==================================
 
 .. automodule:: salt.modules.napalm_network
     :members:

doc/ref/modules/all/salt.modules.netmiko_mod.rst

@@ -0,0 +1,7 @@
+========================
+salt.modules.netmiko_mod
+========================
+
+.. automodule:: salt.modules.netmiko_mod
+    :members:
+

doc/ref/modules/all/salt.modules.opsgenie.rst

@@ -1,6 +1,6 @@
-===================
+=====================
 salt.modules.opsgenie
-===================
+=====================
 
 .. automodule:: salt.modules.opsgenie
     :members:

doc/ref/modules/all/salt.modules.panos.rst

@@ -1,6 +1,6 @@
-===================
+==================
 salt.modules.panos
-===================
+==================
 
 .. automodule:: salt.modules.panos
     :members:

doc/ref/modules/all/salt.modules.pkg.rst

@@ -30,7 +30,7 @@ Execution Module                       Used for
 :py:mod:`~salt.modules.solarispkg`     Solaris-based OSes using ``pkgadd(1M)``
 :py:mod:`~salt.modules.solarisips`     Solaris-based OSes using IPS ``pkg(1)``
 :py:mod:`~salt.modules.win_pkg`        Salt's :ref:`Windows Package Manager
-                                       <windows-package-manager`
+                                       <windows-package-manager>`
 :py:mod:`~salt.modules.yumpkg`         RedHat-based distros and derivatives
                                        using ``yum(8)`` or ``dnf(8)``
 :py:mod:`~salt.modules.zypper`         SUSE-based distros using ``zypper(8)``

doc/ref/modules/all/salt.modules.saltcheck.rst

@@ -0,0 +1,6 @@
+======================
+salt.modules.saltcheck
+======================
+
+.. automodule:: salt.modules.saltcheck
+    :members:

doc/ref/modules/all/salt.modules.service.rst

@@ -33,7 +33,3 @@ Execution Module                       Used for
 :py:mod:`~salt.modules.win_service`    Windows
 ====================================== ========================================
 
-|
-
-.. automodule:: salt.modules.service
-    :members:

doc/ref/modules/all/salt.modules.shadow.rst

@@ -18,9 +18,3 @@ Execution Module                       Used for
 :py:mod:`~salt.modules.solaris_shadow` Solaris-based OSes
 :py:mod:`~salt.modules.win_shadow`     Windows
 ====================================== ========================================
-
-|
-
-.. automodule:: salt.modules.shadow
-    :members:
-

doc/ref/modules/all/salt.modules.template.rst

@@ -0,0 +1,6 @@
+=====================
+salt.modules.template
+=====================
+
+.. automodule:: salt.modules.template
+    :members:

doc/ref/modules/all/salt.modules.win_update.rst

@@ -1,6 +0,0 @@
-=======================
-salt.modules.win_update
-=======================
-
-.. automodule:: salt.modules.win_update
-    :members:

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 <python2:typesmapping>`
+The ``__salt__`` variable is a :ref:`Python dictionary <typesmapping>`
 containing all of the Salt functions. Dictionary keys are strings representing
 the names of the modules and the values are the functions themselves.
 
@@ -157,6 +157,7 @@ Calling Execution Modules on the Salt Master
 ============================================
 
 .. versionadded:: 2016.11.0
+
 Execution modules can now also be called via the :command:`salt-run` command
 using the :ref:`salt runner <salt_salt_runner>`.
 
@@ -175,8 +176,8 @@ Grains Data
 -----------
 
 The values detected by the Salt Grains on the minion are available in a
-:ref:`dict <python2:typesmapping>` named ``__grains__`` and can be accessed
-from within callable objects in the Python modules.
+:ref:`Python dictionary <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
 deployment run the :func:`grains.items` function:
@@ -287,7 +288,7 @@ Virtual module names are set using the ``__virtual__`` function and the
 ``__virtual__`` Function
 ========================
 
-The ``__virtual__`` function returns either a :ref:`string <python2:typesseq>`,
+The ``__virtual__`` function returns either a :ref:`string <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
@@ -509,7 +510,7 @@ To add documentation add a `Python docstring`_ to the function.
 Now when the sys.doc call is executed the docstring will be cleanly returned
 to the calling terminal.
 
-.. _`Python docstring`: http://docs.python.org/2/glossary.html#term-docstring
+.. _`Python docstring`: https://docs.python.org/3/glossary.html#term-docstring
 
 Documentation added to execution modules in docstrings will automatically be
 added to the online web-based documentation.

doc/ref/proxy/all/index.rst

@@ -20,6 +20,7 @@ proxy modules
     junos
     marathon
     napalm
+    netmiko_px
     nxos
     panos
     philips_hue

doc/ref/proxy/all/salt.proxy.napalm.rst

@@ -1,6 +1,6 @@
-================
+=================
 salt.proxy.napalm
-================
+=================
 
 .. automodule:: salt.proxy.napalm
     :members:

doc/ref/proxy/all/salt.proxy.netmiko_px.rst

@@ -0,0 +1,6 @@
+=====================
+salt.proxy.netmiko_px
+=====================
+
+.. automodule:: salt.proxy.netmiko_px
+    :members:

doc/ref/renderers/index.rst

@@ -127,7 +127,7 @@ Other render pipeline combinations include:
 The following is a contrived example SLS file using the ``jinja|mako|yaml``
 render pipeline:
 
-.. code-block:: python
+.. code-block:: text
 
     #!jinja|mako|yaml
 

doc/ref/sdb/all/index.rst

@@ -18,6 +18,7 @@ sdb modules
     etcd_db
     keyring_db
     memcached
+    redis_sdb
     rest
     sqlite3
     tism

doc/ref/sdb/all/salt.sdb.redis_sdb.rst

@@ -0,0 +1,5 @@
+salt.sdb.redis_sdb module
+=========================
+
+.. automodule:: salt.sdb.redis_sdb
+    :members:

doc/ref/states/all/index.rst

@@ -75,7 +75,6 @@ state modules
     debconfmod
     dellchassis
     disk
-    docker
     docker_container
     docker_image
     docker_network
@@ -136,7 +135,6 @@ state modules
     jboss7
     jenkins
     junos
-    k8s
     kapacitor
     kernelpkg
     keyboard
@@ -308,7 +306,6 @@ state modules
     win_smtp_server
     win_snmp
     win_system
-    win_update
     win_wua
     winrepo
     x509
@@ -326,4 +323,5 @@ state modules
     zk_concurrency
     zfs
     zone
+    zookeeper
     zpool

doc/ref/states/all/salt.states.docker.rst

@@ -1,6 +0,0 @@
-==================
-salt.states.docker
-==================
-
-.. automodule:: salt.states.docker
-    :members:

doc/ref/states/all/salt.states.infoblox_a.rst

@@ -1,5 +1,5 @@
-salt.states.infoblox_a module
-===========================
+salt.states.infoblox_a
+======================
 
 .. automodule:: salt.states.infoblox_a
     :members:

doc/ref/states/all/salt.states.infoblox_cname.rst

@@ -1,5 +1,5 @@
-salt.states.infoblox_cname module
-===========================
+salt.states.infoblox_cname
+==========================
 
 .. automodule:: salt.states.infoblox_cname
     :members:

doc/ref/states/all/salt.states.infoblox_host_record.rst

@@ -1,5 +1,5 @@
-salt.states.infoblox_host_record module
-===========================
+salt.states.infoblox_host_record
+================================
 
 .. automodule:: salt.states.infoblox_host_record
     :members:

doc/ref/states/all/salt.states.infoblox_range.rst

@@ -1,5 +1,5 @@
-salt.states.infoblox_range module
-===========================
+salt.states.infoblox_range
+==========================
 
 .. automodule:: salt.states.infoblox_range
     :members:

doc/ref/states/all/salt.states.k8s.rst

@@ -1,6 +0,0 @@
-===============
-salt.states.k8s
-===============
-
-.. automodule:: salt.states.k8s
-    :members:

doc/ref/states/all/salt.states.panos.rst

@@ -1,6 +1,6 @@
-================
+=================
 salt.states.panos
-================
+=================
 
 .. automodule:: salt.states.panos
     :members:

doc/ref/states/all/salt.states.rbac_solaris.rst

@@ -1,4 +1,4 @@
-======------============
+========================
 salt.states.rbac_solaris
 ========================
 

doc/ref/states/all/salt.states.win_update.rst

@@ -1,6 +0,0 @@
-======================
-salt.states.win_update
-======================
-
-.. automodule:: salt.states.win_update
-    :members:

doc/ref/states/compiler_ordering.rst

@@ -1,3 +1,5 @@
+.. _compiler-ordering:
+
 =====================================
 Understanding State Compiler Ordering
 =====================================

doc/ref/states/failhard.rst

@@ -10,6 +10,8 @@ But the situation may exist, where you would want all state execution to stop
 if a single state execution fails. The capability to do this is called
 ``failing hard``.
 
+.. _state-level-failhard:
+
 State Level Failhard
 ====================
 
@@ -36,6 +38,8 @@ executed.
 It is possible to override a Global Failhard (see below) by explicitly setting
 it to ``False`` in the state.
 
+.. _global-failhard:
+
 Global Failhard
 ===============
 
@@ -52,5 +56,5 @@ in states not being executed or even checked. It can also be confusing to
 see states failhard if an admin is not actively aware that the failhard has
 been set.
 
-To use the global failhard set failhard: True in the master configuration
-file.
+To use the global failhard set :conf_master:`failhard` to ``True`` in the
+master configuration file.

doc/ref/states/requisites.rst

@@ -24,7 +24,7 @@ the targeting state. The following example demonstrates a direct requisite:
 .. code-block:: yaml
 
     vim:
-      pkg.installed: []
+      pkg.installed
 
     /etc/vimrc:
       file.managed:
@@ -86,7 +86,7 @@ State target matching
 ~~~~~~~~~~~~~~~~~~~~~
 
 In order to understand how state targets are matched, it is helpful to know
-:ref:`how the state compiler is working <compiler_ordering>`. Consider the following
+:ref:`how the state compiler is working <compiler-ordering>`. Consider the following
 example:
 
 .. code-block:: yaml
@@ -673,7 +673,7 @@ id declaration. This is useful when many files need to have the same defaults.
         - group: apache
         - mode: 755
 
-    /etc/bar.conf
+    /etc/bar.conf:
       file.managed:
         - source: salt://bar.conf
         - use:
@@ -1024,10 +1024,10 @@ same privileges as the salt-minion.
     comment-repo:
       file.replace:
         - name: /etc/yum.repos.d/fedora.repo
-        - pattern: ^enabled=0
+        - pattern: '^enabled=0'
         - repl: enabled=1
         - check_cmd:
-          - ! grep 'enabled=0' /etc/yum.repos.d/fedora.repo
+          - "! grep 'enabled=0' /etc/yum.repos.d/fedora.repo"
 
 This will attempt to do a replace on all ``enabled=0`` in the .repo file, and
 replace them with ``enabled=1``. The ``check_cmd`` is just a bash command. It

doc/ref/states/top.rst

@@ -249,8 +249,8 @@ Match Type   Description
 ============ ================================================================================================================
 glob         Full minion ID or glob expression to match multiple minions (e.g. ``minion123`` or ``minion*``)
 pcre         Perl-compatible regular expression (PCRE) matching a minion ID (e.g.  ``web[0-3].domain.com``)
-grain        Match a :ref:`grain <grain>`, optionally using globbing (e.g. ``kernel:Linux`` or ``kernel:*BSD``)
-grain_pcre   Match a :ref:`grain <grain>` using PCRE (e.g. ``kernel:(Free|Open)BSD``)
+grain        Match a :ref:`grain <grains>`, optionally using globbing (e.g. ``kernel:Linux`` or ``kernel:*BSD``)
+grain_pcre   Match a :ref:`grain <grains>` using PCRE (e.g. ``kernel:(Free|Open)BSD``)
 list         Comma-separated list of minions (e.g. ``minion1,minion2,minion3``)
 pillar       :ref:`Pillar <pillar>` match, optionally using globbing (e.g. ``role:webserver`` or ``role:web*``)
 pillar_pcre  :ref:`Pillar <pillar>` match using PCRE (e.g. ``role:web(server|proxy)``

doc/ref/states/writing.rst

@@ -20,7 +20,7 @@ illustrate:
 
 .. code-block:: yaml
 
-    /etc/salt/master: # maps to "name"
+    /etc/salt/master: # maps to "name", unless a "name" argument is specified below
       file.managed: # maps to <filename>.<function> - e.g. "managed" in https://github.com/saltstack/salt/tree/develop/salt/states/file.py
         - user: root # one of many options passed to the manage function
         - group: root
@@ -50,22 +50,115 @@ directly define the user interface.
     .. _here: https://github.com/saltstack/salt/blob/v0.16.2/salt/states/pkgrepo.py#L163-183
 
 
+Best Practices
+==============
+
+A well-written state function will follow these steps:
+
+.. note::
+    This is an extremely simplified example. Feel free to browse the `source
+    code`_ for Salt's state modules to see other examples.
+
+    .. _`source code`: https://github.com/saltstack/salt/tree/develop/salt/states
+
+1. Set up the return dictionary and perform any necessary input validation
+   (type checking, looking for use of mutually-exclusive arguments, etc.).
+
+   .. code-block:: python
+
+       ret = {'name': name,
+              'result': False,
+              'changes': {},
+              'comment': ''}
+
+       if foo and bar:
+           ret['comment'] = 'Only one of foo and bar is permitted'
+           return ret
+
+2. Check if changes need to be made. This is best done with an
+   information-gathering function in an accompanying :ref:`execution module
+   <writing-execution-modules>`. The state should be able to use the return
+   from this function to tell whether or not the minion is already in the
+   desired state.
+
+   .. code-block:: python
+
+       result = __salt__['modname.check'](name)
+
+3. If step 2 found that the minion is already in the desired state, then exit
+   immediately with a ``True`` result and without making any changes.
+
+   .. code-block:: python
+
+       if result:
+           ret['result'] = True
+           ret['comment'] = '{0} is already installed'.format(name)
+           return ret
+
+4. If step 2 found that changes *do* need to be made, then check to see if the
+   state was being run in test mode (i.e. with ``test=True``). If so, then exit
+   with a ``None`` result, a relevant comment, and (if possible) a ``changes``
+   entry describing what changes would be made.
+
+   .. code-block:: python
+
+       if __opts__['test']:
+           ret['result'] = None
+           ret['comment'] = '{0} would be installed'.format(name)
+           ret['changes'] = result
+           return ret
+
+5. Make the desired changes. This should again be done using a function from an
+   accompanying execution module. If the result of that function is enough to
+   tell you whether or not an error occurred, then you can exit with a
+   ``False`` result and a relevant comment to explain what happened.
+
+   .. code-block:: python
+
+       result = __salt__['modname.install'](name)
+
+6. Perform the same check from step 2 again to confirm whether or not the
+   minion is in the desired state. Just as in step 2, this function should be
+   able to tell you by its return data whether or not changes need to be made.
+
+   .. code-block:: python
+
+       ret['changes'] = __salt__['modname.check'](name)
+
+   As you can see here, we are setting the ``changes`` key in the return
+   dictionary to the result of the ``modname.check`` function (just as we did
+   in step 4). The assumption here is that the information-gathering function
+   will return a dictionary explaining what changes need to be made. This may
+   or may not fit your use case.
+
+7. Set the return data and return!
+
+   .. code-block:: python
+
+       if ret['changes']:
+           ret['comment'] = '{0} failed to install'.format(name)
+       else:
+           ret['result'] = True
+           ret['comment'] = '{0} was installed'.format(name)
+
+       return ret
+
 Using Custom State Modules
 ==========================
 
-Place your custom state modules inside a ``_states`` directory within the
-:conf_master:`file_roots` specified by the master config file. These custom
-state modules can then be distributed in a number of ways. Custom state modules
-are distributed when :py:func:`state.apply <salt.modules.state.apply_>` is run,
-or by executing the :mod:`saltutil.sync_states
+Before the state module can be used, it must be distributed to minions. This
+can be done by placing them into ``salt://_states/``. They can then be
+distributed manually to minions by running :mod:`saltutil.sync_states
 <salt.modules.saltutil.sync_states>` or :mod:`saltutil.sync_all
-<salt.modules.saltutil.sync_all>` functions.
+<salt.modules.saltutil.sync_all>`. Alternatively, when running a
+:ref:`highstate <running-highstate>` custom types will automatically be synced.
 
-Any custom states which have been synced to a minion, that are named the
-same as one of Salt's default set of states, will take the place of the default
-state with the same name. Note that a state's default name is its filename
-(i.e. ``foo.py`` becomes state ``foo``), but that its name can be overridden
-by using a :ref:`__virtual__ function <virtual-modules>`.
+Any custom states which have been synced to a minion, that are named the same
+as one of Salt's default set of states, will take the place of the default
+state with the same name. Note that a state module's name defaults to one based
+on its filename (i.e. ``foo.py`` becomes state module ``foo``), but that its
+name can be overridden by using a :ref:`__virtual__ function
+<virtual-modules>`.
 
 Cross Calling Execution Modules from States
 ===========================================
@@ -97,11 +190,12 @@ 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 <python2:typesmapping>`
-containing all of the state modules. Dictionary keys are strings representing the
-names of the modules and the values are the functions themselves.
+The ``__states__`` variable is a :ref:`Python dictionary <typesmapping>`
+containing all of the state modules. Dictionary keys are strings representing
+the names of the modules and the values are the functions themselves.
 
-Salt state modules can be cross-called by accessing the value in the ``__states__`` dict:
+Salt state modules can be cross-called by accessing the value in the
+``__states__`` dict:
 
 .. code-block:: python
 

doc/topics/beacons/index.rst

@@ -176,7 +176,7 @@ following on the event bus:
 
 .. code-block:: json
 
-    salt/beacon/larry/inotify//etc/important_file	{
+    {
      "_stamp": "2015-09-09T15:59:37.972753",
      "data": {
          "change": "IN_IGNORED",

doc/topics/best_practices.rst

@@ -200,7 +200,7 @@ preferred:
 
 ``/srv/salt/apache/conf.sls``:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% set name = 'httpd' %}
     {% set tmpl = 'salt://apache/files/httpd.conf' %}
@@ -234,7 +234,7 @@ locations within a single state:
 
 ``/srv/salt/apache/conf.sls``:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% from "apache/map.jinja" import apache with context %}
 
@@ -267,7 +267,8 @@ is not very modular to one that is:
 .. code-block:: yaml
 
     httpd:
-      pkg.installed: []
+      pkg:
+        - installed
       service.running:
         - enable: True
 
@@ -331,7 +332,7 @@ modification of static values:
 
 ``/srv/salt/apache/map.jinja``:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% set apache = salt['grains.filter_by']({
         'Debian': {
@@ -357,7 +358,7 @@ modification of static values:
 
 ``/srv/salt/apache/init.sls``:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% from "apache/map.jinja" import apache with context %}
 
@@ -387,7 +388,7 @@ to be broken into two states.
 
 ``/srv/salt/apache/map.jinja``:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% set apache = salt['grains.filter_by']({
         'Debian': {
@@ -414,7 +415,7 @@ to be broken into two states.
 
 ``/srv/salt/apache/init.sls``:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% from "apache/map.jinja" import apache with context %}
 
@@ -427,7 +428,7 @@ to be broken into two states.
 
 ``/srv/salt/apache/conf.sls``:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% from "apache/map.jinja" import apache with context %}
 
@@ -521,7 +522,7 @@ the associated pillar:
 
 ``/srv/salt/mysql/testerdb.sls``:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     testdb:
       mysql_database.present:
@@ -529,7 +530,7 @@ the associated pillar:
 
 ``/srv/salt/mysql/user.sls``:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     include:
       - mysql.testerdb

doc/topics/cloud/aws.rst

@@ -57,6 +57,10 @@ parameters are discussed in more detail below.
       id: 'use-instance-role-credentials'
       key: 'use-instance-role-credentials'
 
+      # If 'role_arn' is specified the above credentials are used to
+      # to assume to the role. By default, role_arn is set to None.
+      role_arn: arn:aws:iam::012345678910:role/SomeRoleName
+
       # Make sure this key is owned by corresponding user (default 'salt') with permissions 0400.
       #
       private_key: /etc/salt/my_test_key.pem
@@ -468,6 +472,19 @@ EC2 API or AWS Console.
       spot_config:
         spot_price: 0.10
 
+You can optionally specify tags to apply to the EC2 spot instance request.
+A spot instance request itself is an object in AWS. The following example
+will set two tags on the spot instance request.
+
+.. code-block:: yaml
+
+    my-ec2-config:
+      spot_config:
+        spot_price: 0.10
+        tag:
+          tag0: value
+          tag1: value
+
 By default, the spot instance type is set to 'one-time', meaning it will
 be launched and, if it's ever terminated for whatever reason, it will not
 be recreated. If you would like your spot instances to be relaunched after

doc/topics/cloud/azure.rst

@@ -21,18 +21,6 @@ Dependencies
 * `Salt <https://github.com/saltstack/salt>`_
 
 
-.. note::
-
-    The Azure driver is currently being updated to work with the new version of
-    the Python Azure SDK, 1.0.0. However until that process is complete, this
-    driver will not work with Azure 1.0.0. Please be sure you're running on a
-    minimum version of 0.10.2 and less than version 1.0.0.
-
-    See `Issue #27980`_ for more information.
-
-.. _Issue #27980: https://github.com/saltstack/salt/issues/27980
-
-
 Configuration
 =============
 

doc/topics/cloud/azurearm.rst

@@ -169,13 +169,19 @@ fields, separated by the pipe (``|``) character:
     sku: Such as 14.04.5-LTS or 2012-R2-Datacenter
     version: Such as 14.04.201612050 or latest
 
-It is possible to specify the URL of a custom image that you have access to,
-such as:
+It is possible to specify the URL or resource ID path of a custom image that you
+have access to, such as:
 
 .. code-block:: yaml
 
     https://<mystorage>.blob.core.windows.net/system/Microsoft.Compute/Images/<mystorage>/template-osDisk.01234567-890a-bcdef0123-4567890abcde.vhd
 
+or:
+
+.. code-block:: yaml
+
+    /subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/myRG/providers/Microsoft.Compute/images/myImage
+
 size
 ----
 Required. The name of the size to use to create a VM. Available sizes can be
@@ -287,6 +293,26 @@ availability_set
 ----------------
 Optional. If set, the VM will be added to the specified availability set.
 
+volumes
+-------
+
+Optional. A list of dictionaries describing data disks to attach to the
+instance can be specified using this setting. The data disk dictionaries are
+passed entirely to the `Azure DataDisk object
+<https://docs.microsoft.com/en-us/python/api/azure.mgmt.compute.v2017_12_01.models.datadisk?view=azure-python>`_,
+so ad-hoc options can be handled as long as they are valid properties of the
+object.
+
+.. code-block:: yaml
+
+    volumes:
+    - disk_size_gb: 50
+      caching: ReadWrite
+    - disk_size_gb: 100
+      caching: ReadWrite
+      managed_disk:
+        storage_account_type: Standard_LRS
+
 cleanup_disks
 -------------
 Optional. Default is ``False``. If set to ``True``, disks will be cleaned up
@@ -329,14 +355,14 @@ How this is used depends on the operating system that is being deployed. If
 used, any ``userdata`` setting will be ignored.
 
 userdata_sendkeys
--------------
+-----------------
 Optional. Set to ``True`` in order to generate salt minion keys and provide
 them as variables to the userdata script when running it through the template
 renderer. The keys can be referenced as ``{{opts['priv_key']}}`` and
 ``{{opts['pub_key']}}``.
 
 userdata_template
--------------
+-----------------
 Optional. Enter the renderer, such as ``jinja``, to be used for the userdata
 script template.
 

doc/topics/cloud/deploy.rst

@@ -257,4 +257,4 @@ This has also been tested to work with pipes, if needed:
 
 .. code-block:: yaml
 
-    script_args: | head
+    script_args: '| head'

doc/topics/cloud/dimensiondata.rst

@@ -2,7 +2,6 @@
 Getting Started With Dimension Data Cloud
 =========================================
 
-
 Dimension Data are a global IT Services company and form part of the NTT Group.
 Dimension Data provide IT-as-a-Service to customers around the globe on their
 cloud platform (Compute as a Service). The CaaS service is available either on
@@ -10,14 +9,15 @@ one of the public cloud instances or as a private instance on premises.
 
 http://cloud.dimensiondata.com/
 
-CaaS has its own non-standard `API`_ , SaltStack provides a 
-wrapper on top of this `API`_ with common methods with other IaaS solutions and
-Public cloud providers. Therefore, you can use the Dimension Data
-module to communicate with both the public and private clouds.
+CaaS has its own non-standard API , SaltStack provides a wrapper on top of this
+API with common methods with other IaaS solutions and Public cloud providers.
+Therefore, you can use the Dimension Data module to communicate with both the
+public and private clouds.
 
 
 Dependencies
 ============
+
 This driver requires the Python ``apache-libcloud`` and ``netaddr`` library to be installed.
 
 
@@ -53,13 +53,14 @@ Possible regions:
       driver: dimensiondata
 
 .. note::
-    .. versionchanged:: 2015.8.0
 
-    The ``provider`` parameter in cloud provider definitions was renamed to ``driver``. This
-    change was made to avoid confusion with the ``provider`` parameter that is used in cloud profile
-    definitions. Cloud provider definitions now use ``driver`` to refer to the Salt cloud module that
-    provides the underlying functionality to connect to a cloud host, while cloud profiles continue
-    to use ``provider`` to refer to provider configurations that you define.
+    In version 2015.8.0, the ``provider`` parameter in cloud provider
+    definitions was renamed to ``driver``. This change was made to avoid
+    confusion with the ``provider`` parameter that is used in cloud profile
+    definitions. Cloud provider definitions now use ``driver`` to refer to the
+    Salt cloud module that provides the underlying functionality to connect to
+    a cloud host, while cloud profiles continue to use ``provider`` to refer to
+    provider configurations that you define.
 
 Profiles
 ========