Merge branch '2017.7' into wheel_error_error

.ci/docs

@@ -0,0 +1,50 @@
+pipeline {
+    agent { label 'docs' }
+    options {
+        timestamps()
+        ansiColor('xterm')
+    }
+    environment {
+        PYENV_ROOT = "/usr/local/pyenv"
+        PATH = "$PYENV_ROOT/bin:$PATH"
+        PY_COLORS = 1
+    }
+    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'
+            }
+        }
+    }
+    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,73 @@
+pipeline {
+    agent { label 'kitchen-slave' }
+    options {
+        timestamps()
+        ansiColor('xterm')
+    }
+    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"
+        PY_COLORS = 1
+    }
+    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'
+                    }
+                }}
+            }
+            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'
+                        }
+                    }}
+                    archiveArtifacts artifacts: 'artifacts/xml-unittests-output/*.xml'
+                    archiveArtifacts artifacts: 'artifacts/logs/minion'
+                    archiveArtifacts artifacts: 'artifacts/logs/salt-runtests.log'
+                }
+            }
+        }
+    }
+    post {
+        always {
+            junit 'artifacts/xml-unittests-output/*.xml'
+            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,73 @@
+pipeline {
+    agent { label 'kitchen-slave' }
+    options {
+        timestamps()
+        ansiColor('xterm')
+    }
+    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"
+        PY_COLORS = 1
+    }
+    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'
+                    }
+                }}
+            }
+            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'
+                        }
+                    }}
+                    archiveArtifacts artifacts: 'artifacts/xml-unittests-output/*.xml'
+                    archiveArtifacts artifacts: 'artifacts/logs/minion'
+                    archiveArtifacts artifacts: 'artifacts/logs/salt-runtests.log'
+                }
+            }
+        }
+    }
+    post {
+        always {
+            junit 'artifacts/xml-unittests-output/*.xml'
+            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,73 @@
+pipeline {
+    agent { label 'kitchen-slave' }
+    options {
+        timestamps()
+        ansiColor('xterm')
+    }
+    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"
+        PY_COLORS = 1
+    }
+    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'
+                    }
+                }}
+            }
+            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'
+                        }
+                    }}
+                    archiveArtifacts artifacts: 'artifacts/xml-unittests-output/*.xml'
+                    archiveArtifacts artifacts: 'artifacts/logs/minion'
+                    archiveArtifacts artifacts: 'artifacts/logs/salt-runtests.log'
+                }
+            }
+        }
+    }
+    post {
+        always {
+            junit 'artifacts/xml-unittests-output/*.xml'
+            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,73 @@
+pipeline {
+    agent { label 'kitchen-slave' }
+    options {
+        timestamps()
+        ansiColor('xterm')
+    }
+    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"
+        PY_COLORS = 1
+    }
+    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'
+                    }
+                }}
+            }
+            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'
+                        }
+                    }}
+                    archiveArtifacts artifacts: 'artifacts/xml-unittests-output/*.xml'
+                    archiveArtifacts artifacts: 'artifacts/logs/minion'
+                    archiveArtifacts artifacts: 'artifacts/logs/salt-runtests.log'
+                }
+            }
+        }
+    }
+    post {
+        always {
+            junit 'artifacts/xml-unittests-output/*.xml'
+            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,72 @@
+pipeline {
+    agent { label 'pr-lint-slave' }
+    options {
+        timestamps()
+        ansiColor('xterm')
+    }
+    environment {
+        PYENV_ROOT = "/usr/local/pyenv"
+        PATH = "$PYENV_ROOT/bin:$PATH"
+        PY_COLORS = 1
+    }
+    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 tox'
+            }
+        }
+        stage('linting') {
+            failFast false
+            parallel {
+                stage('salt linting') {
+                    steps {
+                        sh 'eval "$(pyenv init - --no-rehash)"; tox -e pylint-salt $(find salt/ -name "*.py" -exec git diff --name-only "origin/$CHANGE_TARGET" "origin/$BRANCH_NAME" setup.py {} +) | tee pylint-report.xml'
+                        archiveArtifacts artifacts: 'pylint-report.xml'
+                    }
+                }
+                stage('test linting') {
+                    steps {
+                        sh 'eval "$(pyenv init - --no-rehash)"; tox -e pylint-tests $(find tests/ -name "*.py" -exec git diff --name-only "origin/$CHANGE_TARGET" "origin/$BRANCH_NAME" {} +) | tee pylint-report-tests.xml'
+                        archiveArtifacts artifacts: 'pylint-report-tests.xml'
+                    }
+                }
+            }
+        }
+    }
+    post {
+        always {
+            step([$class: 'WarningsPublisher',
+                parserConfigurations: [[
+                    parserName: 'PyLint',
+                    pattern: 'pylint-report*.xml'
+                ]],
+                failedTotalAll: '0',
+                useDeltaValues: false,
+                canRunOnFailed: true,
+                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/CODEOWNERS

@@ -48,6 +48,7 @@ salt/spm/*                          @saltstack/team-spm
 # Team SSH
 salt/cli/ssh.py                     @saltstack/team-ssh
 salt/client/ssh/*                   @saltstack/team-ssh
+salt/roster/*                       @saltstack/team-ssh
 salt/runners/ssh.py                 @saltstack/team-ssh
 salt/**/thin.py                     @saltstack/team-ssh
 

.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,21 +43,20 @@ provisioner:
     repo: git
     testingdir: /testing
   salt_copy_filter:
+    - __pycache__
+    - '*.pyc'
     - .bundle
+    - .tox
     - .kitchen
-    - .kitchen.yml
     - artifacts
-    - Gemfile
     - Gemfile.lock
-    - README.rst
-    - .travis.yml
   state_top:
     base:
       "os:Windows":
         - match: grain
         - prep_windows
       "*":
-        - git.salt
+        - <%= ENV['KITCHEN_STATE'] || 'git.salt' %>
   pillars:
     top.sls:
       base:

Gemfile

@@ -11,16 +11,11 @@ group :docker do
   gem 'kitchen-docker', :git => 'https://github.com/test-kitchen/kitchen-docker.git'
 end
 
-group :opennebula do
-  gem 'kitchen-opennebula', '>=0.2.3'
-  gem 'xmlrpc'
-end
-
 group :windows do
   gem 'vagrant-wrapper'
   gem 'kitchen-vagrant'
   gem 'winrm', '~>2.0'
-  gem 'winrm-fs', :git => 'https://github.com/WinRb/winrm-fs.git'
+  gem 'winrm-fs', '~>1.2.1'
 end
 
 group :ec2 do

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/_themes/saltstack2/layout.html

@@ -138,7 +138,7 @@
                             <span class="icon-bar"></span>
                             <span class="icon-bar"></span>
                         </button>
-                        <a href="http://saltstack.com/" target="_blank"><img src="{{ pathto('_static/images/saltstack.svg', 1) }}" class="nolightbox" height="40px" width="170px"></a>
+                        <a href="http://saltstack.com/" target="_blank"><img src="{{ pathto('_static/images/SaltStack_white.svg', 1) }}" class="nolightbox" height="40px" width="170px"></a>
                     </div>
                     <!-- Collect the nav links, forms, and other content for toggling -->
                     <div class="collapse navbar-collapse" id="navbarCollapse">
@@ -252,13 +252,11 @@
                                     <p>© {{ copyright }} SaltStack. All Rights Reserved, SaltStack Inc. | <a href="http://saltstack.com/privacy-policy" target="_blank">Privacy Policy</a></p>
                                 </div>
                             </div>
-
                             <div class="col-sm-6">
-
+                                 <!--
                                  <a href="https://saltstack.com/saltstack-enterprise/" target="_blank"><img class="nolightbox footer-banner center" src="{{ pathto('_static/images/enterprise_ad.jpg', 1) }}"/></a>
+                                 -->
                                  <a href="http://saltconf.com" target="_blank"><img class="nolightbox footer-banner center" src="{{ pathto('_static/images/DOCBANNER.jpg', 1) }}"/></a>
-
-
                             </div>
                             {% endif %}
                         </div>

doc/_themes/saltstack2/static/images/SaltStack_white.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 301.57 44.47"><defs><style>.cls-1{fill:#fff;}</style></defs><title>Asset 2</title><g id="Layer_2" data-name="Layer 2"><g id="Layer_1-2" data-name="Layer 1"><path class="cls-1" d="M50.63,6.05h8.79L72.58,43.24H64.15L61.7,35.6H48l-2.52,7.64H37.35Zm-.51,23.14h9.52l-4.7-14.64Z"/><path class="cls-1" d="M76.12,6.05h7.77V36.56h18.58v6.68H76.12Z"/><path class="cls-1" d="M127.07,6.05v6.58H115.94V43.24h-7.82V12.63H96.94V6.05Z"/><path class="cls-1" d="M190.53,6.05v6.58H179.41V43.24h-7.83V12.63H160.4V6.05Z"/><path class="cls-1" d="M200.41,6.05h8.8l13.16,37.19h-8.43l-2.45-7.64h-13.7l-2.52,7.64h-8.13Zm-.51,23.14h9.53l-4.7-14.64Z"/><path class="cls-1" d="M227.91,10.17a15.34,15.34,0,0,1,11.34-4.83q9.28-.2,13.71,5.87a13.46,13.46,0,0,1,2.69,6.89l-7.77.16a10.78,10.78,0,0,0-2-4A7.68,7.68,0,0,0,239.68,12a7.59,7.59,0,0,0-6.48,3.56Q230.88,19,231,25.25t2.73,9.32a7.91,7.91,0,0,0,6.49,3,7.27,7.27,0,0,0,6-2.8,11.86,11.86,0,0,0,1.84-4.35l7.72-.17a16.79,16.79,0,0,1-4.9,10,14.83,14.83,0,0,1-10.44,4q-7.94.16-12.59-4.88t-4.84-14.09Q222.85,15.56,227.91,10.17Z"/><path class="cls-1" d="M260.39,6.05H268V21.37L282.4,6.05h10.05L277.18,21.34l16.05,21.9h-10L271.78,27,268,30.8V43.24h-7.64Z"/><path class="cls-1" d="M15.65,12.47a9.05,9.05,0,0,1,4.6-1.05,10.15,10.15,0,0,1,4.63.94,5.29,5.29,0,0,1,3,4.77h7.47a11.06,11.06,0,0,0-4.4-9A16.57,16.57,0,0,0,20.79,5a23,23,0,0,0-5.14.54Z"/><path class="cls-1" d="M33.21,24.77a16.6,16.6,0,0,0-6.43-2.7l-6.53-1.54A22.45,22.45,0,0,1,15.31,19a3.18,3.18,0,0,1-1.81-3c0-.12,0-.22,0-.34H6.35c0,.3,0,.59,0,.9q0,5.47,3.76,8.05,2.22,1.54,8.15,2.85l4,.89a17.48,17.48,0,0,1,5.17,1.74A3.17,3.17,0,0,1,29,33c0,2.1-1.1,3.54-3.32,4.31a14.08,14.08,0,0,1-4.56.61c-3.13,0-5.33-.77-6.62-2.3a7.48,7.48,0,0,1-1.42-3.81H5.7a11,11,0,0,0,4.21,9.12q4.22,3.33,11.56,3.32,7.19,0,11.13-3.37a10.64,10.64,0,0,0,3.94-8.46A9.1,9.1,0,0,0,33.21,24.77Z"/><path class="cls-1" d="M137.55,12.73a9,9,0,0,1,4.6-1.05,10.18,10.18,0,0,1,4.63.94,5.33,5.33,0,0,1,3,4.77h7.47a11,11,0,0,0-4.41-9,16.54,16.54,0,0,0-10.15-3.12,23,23,0,0,0-5.14.54Z"/><path class="cls-1" d="M155.11,25a16.83,16.83,0,0,0-6.43-2.7l-6.53-1.54a21.71,21.71,0,0,1-4.94-1.54,3.17,3.17,0,0,1-1.81-3c0-.13,0-.23,0-.35h-7.19c0,.3-.05.6-.05.9,0,3.65,1.26,6.34,3.77,8.05,1.48,1,4.19,2,8.15,2.85l4,.89a17.29,17.29,0,0,1,5.16,1.74,3.16,3.16,0,0,1,1.63,2.85q0,3.15-3.32,4.32a14.39,14.39,0,0,1-4.56.6c-3.13,0-5.34-.76-6.62-2.3A7.48,7.48,0,0,1,135,32H127.6a11,11,0,0,0,4.21,9.13c2.8,2.21,6.66,3.32,11.55,3.32s8.51-1.13,11.14-3.37a10.7,10.7,0,0,0,3.94-8.47A9.1,9.1,0,0,0,155.11,25Z"/><rect class="cls-1" width="9.85" height="9.85"/><path class="cls-1" d="M299.8,40.44a.94.94,0,0,0,.16-.57,1.06,1.06,0,0,0-.08-.45.82.82,0,0,0-.24-.32,1,1,0,0,0-.38-.19,1.72,1.72,0,0,0-.52-.07h-1.2v3.4h.59V40.93h.66l.68,1.31h.63v0l-.76-1.42A1,1,0,0,0,299.8,40.44Zm-.59-.14a.52.52,0,0,1-.19.12,1.18,1.18,0,0,1-.28,0h-.61V39.32h.61a.79.79,0,0,1,.28,0,.55.55,0,0,1,.2.11.76.76,0,0,1,.12.19.85.85,0,0,1,0,.23.56.56,0,0,1,0,.23A.36.36,0,0,1,299.21,40.3Z"/><path class="cls-1" d="M298.7,37.68a2.88,2.88,0,1,0,2.87,2.87A2.88,2.88,0,0,0,298.7,37.68Zm0,5.27a2.4,2.4,0,1,1,2.39-2.4A2.41,2.41,0,0,1,298.7,43Z"/></g></g></svg>

doc/conf.py

@@ -106,6 +106,7 @@ MOCK_MODULES = [
 
     'tornado',
     'tornado.concurrent',
+    'tornado.escape',
     'tornado.gen',
     'tornado.httpclient',
     'tornado.httpserver',
@@ -137,8 +138,8 @@ MOCK_MODULES = [
     'pymongo',
     'rabbitmq_server',
     'redis',
-    'requests',
+    #'requests',
-    'requests.exceptions',
+    #'requests.exceptions',
     'rpm',
     'rpmUtils',
     'rpmUtils.arch',
@@ -237,8 +238,7 @@ formulas_dir = os.path.join(os.pardir, docs_basepath, 'formulas')
 
 # ----- Intersphinx Settings ------------------------------------------------>
 intersphinx_mapping = {
-        'python2': ('http://docs.python.org/2', None),
+    'python': ('https://docs.python.org/3', None)
-        'python3': ('http://docs.python.org/3', None)
 }
 # <---- Intersphinx Settings -------------------------------------------------
 
@@ -250,8 +250,8 @@ on_saltstack = 'SALT_ON_SALTSTACK' in os.environ
 project = 'Salt'
 
 version = salt.version.__version__
-latest_release = '2018.3.0'  # latest release
+latest_release = '2018.3.2'  # latest release
-previous_release = '2017.7.5'  # latest release from previous branch
+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
@@ -357,9 +357,8 @@ rst_prolog = """\
 # 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 #'),
-    'issue': ('https://github.com/saltstack/salt/issues/%s', 'issue '),
+    'pull': ('https://github.com/saltstack/salt/pull/%s', 'PR #'),
-    '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,11 +16,15 @@ 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/virt/index
     ref/cli/index
+    ref/pillar/index
+    ref/tops/index
     ref/index
     topics/api
     topics/topology/index
@@ -28,3 +33,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>`,
+:py:func:`saltutil.sync_modules <salt.modules.saltutil.sync_modules>`,
-or :mod:`saltutil.sync_all <salt.modules.saltutil.sync_all>` is run.
+or :py:func:`saltutil.sync_all <salt.modules.saltutil.sync_all>` is run.
-Custom modules are also synced by :mod:`state.apply` when run without
-any arguments.
 
+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
+They are both also synced when a :ref:`highstate <running-highstate>` is
-when :mod:`state.apply <salt.modules.state.apply_>`,
+triggered.
-:mod:`saltutil.sync_states <salt.modules.saltutil.sync_states>`, or
-:mod:`saltutil.sync_all <salt.modules.saltutil.sync_all>` is run.
 
-Custom states are also synced by :mod:`state.apply<salt.modules.state.apply_>`
+As of the Fluorine release, as well as 2017.7.7 and 2018.3.2 in their
-when run without any arguments.
+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 07, 2018" "2017.7.6" "Salt"
+.TH "SALT-API" "1" "August 06, 2018" "2017.7.8" "Salt"
 .SH NAME
 salt-api \- salt-api Command
 .
@@ -103,9 +103,9 @@ Logfile logging log level. One of \fBall\fP, \fBgarbage\fP, \fBtrace\fP,
 .UNINDENT
 .SH SEE ALSO
 .sp
-\fBsalt\-api(7)\fP
+\fIsalt\-api(7)\fP
-\fBsalt(7)\fP
+\fIsalt(7)\fP
-\fBsalt\-master(1)\fP
+\fIsalt\-master(1)\fP
 .SH AUTHOR
 Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
 .\" Generated by docutils manpage writer.

doc/man/salt-call.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-CALL" "1" "May 07, 2018" "2017.7.6" "Salt"
+.TH "SALT-CALL" "1" "August 06, 2018" "2017.7.8" "Salt"
 .SH NAME
 salt-call \- salt-call Documentation
 .
@@ -265,9 +265,9 @@ output. Set to True or False. Default: none.
 .UNINDENT
 .SH SEE ALSO
 .sp
-\fBsalt(1)\fP
+\fIsalt(1)\fP
-\fBsalt\-master(1)\fP
+\fIsalt\-master(1)\fP
-\fBsalt\-minion(1)\fP
+\fIsalt\-minion(1)\fP
 .SH AUTHOR
 Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
 .\" Generated by docutils manpage writer.

doc/man/salt-cloud.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-CLOUD" "1" "May 07, 2018" "2017.7.6" "Salt"
+.TH "SALT-CLOUD" "1" "August 06, 2018" "2017.7.8" "Salt"
 .SH NAME
 salt-cloud \- Salt Cloud Command
 .
@@ -387,10 +387,10 @@ salt\-cloud \-m /path/to/cloud.map \-Q
 .UNINDENT
 .SH SEE ALSO
 .sp
-\fBsalt\-cloud(7)\fP
+\fIsalt\-cloud(7)\fP
-\fBsalt(7)\fP
+\fIsalt(7)\fP
-\fBsalt\-master(1)\fP
+\fIsalt\-master(1)\fP
-\fBsalt\-minion(1)\fP
+\fIsalt\-minion(1)\fP
 .SH AUTHOR
 Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
 .\" Generated by docutils manpage writer.

doc/man/salt-cp.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-CP" "1" "May 07, 2018" "2017.7.6" "Salt"
+.TH "SALT-CP" "1" "August 06, 2018" "2017.7.8" "Salt"
 .SH NAME
 salt-cp \- salt-cp Documentation
 .
@@ -201,9 +201,9 @@ New in version 2016.3.7,2016.11.6,2017.7.0.
 .UNINDENT
 .SH SEE ALSO
 .sp
-\fBsalt(1)\fP
+\fIsalt(1)\fP
-\fBsalt\-master(1)\fP
+\fIsalt\-master(1)\fP
-\fBsalt\-minion(1)\fP
+\fIsalt\-minion(1)\fP
 .SH AUTHOR
 Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
 .\" Generated by docutils manpage writer.

doc/man/salt-key.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-KEY" "1" "May 07, 2018" "2017.7.6" "Salt"
+.TH "SALT-KEY" "1" "August 06, 2018" "2017.7.8" "Salt"
 .SH NAME
 salt-key \- salt-key Documentation
 .
@@ -340,9 +340,9 @@ Auto\-create a signing key\-pair if it does not yet exist
 .UNINDENT
 .SH SEE ALSO
 .sp
-\fBsalt(7)\fP
+\fIsalt(7)\fP
-\fBsalt\-master(1)\fP
+\fIsalt\-master(1)\fP
-\fBsalt\-minion(1)\fP
+\fIsalt\-minion(1)\fP
 .SH AUTHOR
 Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
 .\" Generated by docutils manpage writer.

doc/man/salt-master.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-MASTER" "1" "May 07, 2018" "2017.7.6" "Salt"
+.TH "SALT-MASTER" "1" "August 06, 2018" "2017.7.8" "Salt"
 .SH NAME
 salt-master \- salt-master Documentation
 .
@@ -108,9 +108,9 @@ Logfile logging log level. One of \fBall\fP, \fBgarbage\fP, \fBtrace\fP,
 .UNINDENT
 .SH SEE ALSO
 .sp
-\fBsalt(1)\fP
+\fIsalt(1)\fP
-\fBsalt(7)\fP
+\fIsalt(7)\fP
-\fBsalt\-minion(1)\fP
+\fIsalt\-minion(1)\fP
 .SH AUTHOR
 Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
 .\" Generated by docutils manpage writer.

doc/man/salt-minion.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-MINION" "1" "May 07, 2018" "2017.7.6" "Salt"
+.TH "SALT-MINION" "1" "August 06, 2018" "2017.7.8" "Salt"
 .SH NAME
 salt-minion \- salt-minion Documentation
 .
@@ -109,9 +109,9 @@ Logfile logging log level. One of \fBall\fP, \fBgarbage\fP, \fBtrace\fP,
 .UNINDENT
 .SH SEE ALSO
 .sp
-\fBsalt(1)\fP
+\fIsalt(1)\fP
-\fBsalt(7)\fP
+\fIsalt(7)\fP
-\fBsalt\-master(1)\fP
+\fIsalt\-master(1)\fP
 .SH AUTHOR
 Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
 .\" Generated by docutils manpage writer.

doc/man/salt-proxy.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-PROXY" "1" "May 07, 2018" "2017.7.6" "Salt"
+.TH "SALT-PROXY" "1" "August 06, 2018" "2017.7.8" "Salt"
 .SH NAME
 salt-proxy \- salt-proxy Documentation
 .
@@ -116,10 +116,10 @@ Logfile logging log level. One of \fBall\fP, \fBgarbage\fP, \fBtrace\fP,
 .UNINDENT
 .SH SEE ALSO
 .sp
-\fBsalt(1)\fP
+\fIsalt(1)\fP
-\fBsalt(7)\fP
+\fIsalt(7)\fP
-\fBsalt\-master(1)\fP
+\fIsalt\-master(1)\fP
-\fBsalt\-minion(1)\fP
+\fIsalt\-minion(1)\fP
 .SH AUTHOR
 Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
 .\" Generated by docutils manpage writer.

doc/man/salt-run.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-RUN" "1" "May 07, 2018" "2017.7.6" "Salt"
+.TH "SALT-RUN" "1" "August 06, 2018" "2017.7.8" "Salt"
 .SH NAME
 salt-run \- salt-run Documentation
 .
@@ -114,9 +114,9 @@ Logfile logging log level. One of \fBall\fP, \fBgarbage\fP, \fBtrace\fP,
 .UNINDENT
 .SH SEE ALSO
 .sp
-\fBsalt(1)\fP
+\fIsalt(1)\fP
-\fBsalt\-master(1)\fP
+\fIsalt\-master(1)\fP
-\fBsalt\-minion(1)\fP
+\fIsalt\-minion(1)\fP
 .SH AUTHOR
 Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
 .\" Generated by docutils manpage writer.

doc/man/salt-ssh.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-SSH" "1" "May 07, 2018" "2017.7.6" "Salt"
+.TH "SALT-SSH" "1" "August 06, 2018" "2017.7.8" "Salt"
 .SH NAME
 salt-ssh \- salt-ssh Documentation
 .
@@ -348,9 +348,9 @@ output. Set to True or False. Default: none.
 .UNINDENT
 .SH SEE ALSO
 .sp
-\fBsalt(7)\fP
+\fIsalt(7)\fP
-\fBsalt\-master(1)\fP
+\fIsalt\-master(1)\fP
-\fBsalt\-minion(1)\fP
+\fIsalt\-minion(1)\fP
 .SH AUTHOR
 Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
 .\" Generated by docutils manpage writer.

doc/man/salt-syndic.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-SYNDIC" "1" "May 07, 2018" "2017.7.6" "Salt"
+.TH "SALT-SYNDIC" "1" "August 06, 2018" "2017.7.8" "Salt"
 .SH NAME
 salt-syndic \- salt-syndic Documentation
 .
@@ -110,9 +110,9 @@ Logfile logging log level. One of \fBall\fP, \fBgarbage\fP, \fBtrace\fP,
 .UNINDENT
 .SH SEE ALSO
 .sp
-\fBsalt(1)\fP
+\fIsalt(1)\fP
-\fBsalt\-master(1)\fP
+\fIsalt\-master(1)\fP
-\fBsalt\-minion(1)\fP
+\fIsalt\-minion(1)\fP
 .SH AUTHOR
 Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
 .\" Generated by docutils manpage writer.

doc/man/salt-unity.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT-UNITY" "1" "May 07, 2018" "2017.7.6" "Salt"
+.TH "SALT-UNITY" "1" "August 06, 2018" "2017.7.8" "Salt"
 .SH NAME
 salt-unity \- salt-unity Command
 .
@@ -50,17 +50,17 @@ invokes that script.
 .SH OPTIONS
 .SH SEE ALSO
 .sp
-\fBsalt\-api(1)\fP
+\fIsalt\-api(1)\fP
-\fBsalt\-call(1)\fP
+\fIsalt\-call(1)\fP
-\fBsalt\-cloud(1)\fP
+\fIsalt\-cloud(1)\fP
-\fBsalt\-cp(1)\fP
+\fIsalt\-cp(1)\fP
-\fBsalt\-key(1)\fP
+\fIsalt\-key(1)\fP
-\fBsalt\-main(1)\fP
+\fIsalt\-main(1)\fP
-\fBsalt\-master(1)\fP
+\fIsalt\-master(1)\fP
-\fBsalt\-minion(1)\fP
+\fIsalt\-minion(1)\fP
-\fBsalt\-run(1)\fP
+\fIsalt\-run(1)\fP
-\fBsalt\-ssh(1)\fP
+\fIsalt\-ssh(1)\fP
-\fBsalt\-syndic(1)\fP
+\fIsalt\-syndic(1)\fP
 .SH AUTHOR
 Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
 .\" Generated by docutils manpage writer.

doc/man/salt.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SALT" "1" "May 07, 2018" "2017.7.6" "Salt"
+.TH "SALT" "1" "August 06, 2018" "2017.7.8" "Salt"
 .SH NAME
 salt \- salt
 .
@@ -95,16 +95,6 @@ the started execution and complete.
 .UNINDENT
 .INDENT 0.0
 .TP
-.B \-\-state\-output=STATE_OUTPUT
-New in version 0.17.
-
-.sp
-Override the configured \fBstate_output\fP value for minion output. One of
-\fBfull\fP, \fBterse\fP, \fBmixed\fP, \fBchanges\fP or \fBfilter\fP\&.  Default:
-\fBfull\fP\&.
-.UNINDENT
-.INDENT 0.0
-.TP
 .B \-\-subset=SUBSET
 Execute the routine on a random subset of the targeted minions.  The
 minions will be verified that they have the named function before
@@ -344,9 +334,9 @@ output. Set to True or False. Default: none.
 .UNINDENT
 .SH SEE ALSO
 .sp
-\fBsalt(7)\fP
+\fIsalt(7)\fP
-\fBsalt\-master(1)\fP
+\fIsalt\-master(1)\fP
-\fBsalt\-minion(1)\fP
+\fIsalt\-minion(1)\fP
 .SH AUTHOR
 Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
 .\" Generated by docutils manpage writer.

doc/man/spm.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "SPM" "1" "May 07, 2018" "2017.7.6" "Salt"
+.TH "SPM" "1" "August 06, 2018" "2017.7.8" "Salt"
 .SH NAME
 spm \- Salt Package Manager Command
 .
@@ -132,9 +132,9 @@ in that directory which describes them.
 .UNINDENT
 .SH SEE ALSO
 .sp
-\fBsalt(1)\fP
+\fIsalt(1)\fP
-\fBsalt\-master(1)\fP
+\fIsalt\-master(1)\fP
-\fBsalt\-minion(1)\fP
+\fIsalt\-minion(1)\fP
 .SH AUTHOR
 Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
 .\" Generated by docutils manpage writer.

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

@@ -1,5 +1,5 @@
 salt.beacons.sensehat module
-=======================
+============================
 
 .. automodule:: salt.beacons.sensehat
     :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.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/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
+and can be found in the official :ref:`Python documentation <python:levels>`.
-<https://docs.python.org/library/logging.html#levels>`_.  Salt uses some more
+Salt uses some more levels in addition to the standard levels.  All levels
-levels in addition to the standard levels.  All levels available in salt are
+available in salt are shown in the table below.
-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
+.. code-block:: text
-:ref:`SysLogHandler documentation
+
-<python2:logging.handlers.SysLogHandler.encodePriority>` . It defaults to
+    <file|udp|tcp>://<host|socketpath>:<port-if-required>/<log-facility>
-``LOG_USER``.
+
+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
+:py:class:`~logging.LogRecord` attributes can be used. Salt also provides these
-also provides these custom LogRecord attributes to colorize console log output:
+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
+:py:class:`~logging.LogRecord` attributes can be used.  Salt also provides
-also provides these custom LogRecord attributes that include padding and
+these custom LogRecord attributes that include padding and enclosing brackets
-enclosing brackets ``[`` and ``]``:
+``[`` and ``]``:
 
 .. code-block:: python
 

doc/ref/configuration/master.rst

@@ -696,31 +696,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-black:: yaml
-
-    ping_on_rotate: False
-
 .. conf_master:: master_job_cache
 
 ``master_job_cache``
@@ -840,8 +815,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
+what you are doing!
-<transports>`.
 
 .. code-block:: yaml
 
@@ -854,10 +828,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
+(experimental) Starts multiple transports and overrides options for each
-This setting has a significant impact on performance and should not be changed unless you know
+transport with the provided dictionary This setting has a significant impact on
-what you are doing! Transports are explained in :ref:`Salt Transports
+performance and should not be changed unless you know what you are doing!  The
-<transports>`. The following example shows how to start a TCP transport alongside a ZMQ transport.
+following example shows how to start a TCP transport alongside a ZMQ transport.
 
 .. code-block:: yaml
 
@@ -903,7 +877,7 @@ is set to ``tcp`` by default on Windows.
 
     ipc_mode: ipc
 
-.. conf_master::
+.. conf_master:: tcp_master_pub_port
 
 ``tcp_master_pub_port``
 -----------------------
@@ -976,7 +950,7 @@ a minion performs an authentication check with the master.
 .. conf_master:: minion_data_cache_events
 
 ``minion_data_cache_events``
---------------------
+----------------------------
 
 .. versionadded:: 2017.7.3
 
@@ -994,6 +968,23 @@ cache events are fired when a minion requests a minion data cache refresh.
 Salt-SSH Configuration
 ======================
 
+.. 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``
@@ -1587,10 +1578,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``
 
@@ -1619,8 +1610,27 @@ 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
 
+.. conf_master:: optimization_order
+
+``optimization_order``
+----------------------
+
+Default: ``[0, 1, 2]``
+
+In cases where Salt is distributed without .py files, this option determines
+the priority of optimization level(s) Salt's module loader should prefer.
+
+.. note::
+    This option is only supported on Python 3.5+.
+
+.. code-block:: yaml
+
+    optimization_order:
+      - 2
+      - 0
+      - 1
 
 Master Large Scale Tuning Settings
 ==================================
@@ -3868,7 +3878,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
@@ -3916,12 +3926,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
 
@@ -4169,6 +4181,7 @@ Default: ``10``
 The number of workers for the runner/wheel in the reactor.
 
 .. code-block:: yaml
+
     reactor_worker_threads: 10
 
 .. conf_master:: reactor_worker_hwm
@@ -5017,7 +5030,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

@@ -306,7 +306,7 @@ option on the Salt master.
 .. conf_minion:: publish_port
 
 ``publish_port``
----------------
+----------------
 
 Default: ``4505``
 
@@ -432,7 +432,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,
@@ -822,7 +822,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``
 --------------
@@ -1090,8 +1090,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
+what you are doing!
-<transports>`.
 
 .. code-block:: yaml
 
@@ -1163,6 +1162,59 @@ The password used for HTTP proxy access.
 
     proxy_password: obolus
 
+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:: optimization_order
+
+``optimization_order``
+----------------------
+
+Default: ``[0, 1, 2]``
+
+In cases where Salt is distributed without .py files, this option determines
+the priority of optimization level(s) Salt's module loader should prefer.
+
+.. note::
+    This option is only supported on Python 3.5+.
+
+.. code-block:: yaml
+
+    optimization_order:
+      - 2
+      - 0
+      - 1
+
 Minion Module Management
 ========================
 
@@ -1370,7 +1422,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
 
@@ -2330,6 +2382,7 @@ Default: ``10``
 The number of workers for the runner/wheel in the reactor.
 
 .. code-block:: yaml
+
     reactor_worker_threads: 10
 
 .. conf_minion:: reactor_worker_hwm
@@ -2352,7 +2405,7 @@ Thread Settings
 .. conf_minion:: multiprocessing
 
 ``multiprocessing``
--------
+-------------------
 
 Default: ``True``
 

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/grains/all/salt.grains.metadata.rst

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

doc/ref/index.rst

@@ -13,6 +13,7 @@ This section contains a list of the Python modules that are used to extend the v
     ../ref/cache/all/index
     ../ref/clouds/all/index
     ../ref/engines/all/index
+    ../ref/executors/all/index
     ../ref/file_server/all/index
     ../ref/grains/all/index
     ../ref/modules/all/index

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,
+1) Salt should convert whatever data is passed on CLI/API to Unicode.
-everything that Salt does should be Unicode unless it is printing to the screen
+   Internally, everything that Salt does should be Unicode unless it is
-or writing to storage.
+   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
+4) When Salt delivers the data to an outputter or a returner, it is the job of
-or returner to encode the Unicode before displaying it on the console or writing it to storage.
+   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

@@ -10,6 +10,8 @@ execution modules
 
         salt.modules.group
         salt.modules.pkg
+        salt.modules.service
+        salt.modules.shadow
         salt.modules.user
 
 .. currentmodule:: salt.modules
@@ -94,7 +96,6 @@ execution modules
     cron
     csf
     cyg
-    cytest
     daemontools
     data
     ddns
@@ -200,6 +201,7 @@ execution modules
     layman
     ldap3
     ldapmod
+    libcloud_dns
     linux_acl
     linux_ip
     linux_lvm

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.napalm_network.rst

@@ -1,5 +1,5 @@
 salt.modules.napalm_network module
-===============================
+==================================
 
 .. automodule:: salt.modules.napalm_network
     :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.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/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
+:ref:`Python dictionary <typesmapping>` named ``__grains__`` and can be
-from within callable objects in the Python modules.
+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:
@@ -264,7 +265,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
@@ -481,7 +482,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/salt.proxy.napalm.rst

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

doc/ref/renderers/index.rst

@@ -77,7 +77,7 @@ Other renderer combinations are possible:
 
 The following is a contrived example SLS file using the ``jinja | mako | yaml`` renderer:
 
-.. code-block:: python
+.. code-block:: text
 
     #!jinja|mako|yaml
 

doc/ref/returners/index.rst

@@ -71,9 +71,9 @@ Other optional functions can be included to add support for
         '''
         # Get a redis connection
         serv = redis.Redis(
-                    host='redis-serv.example.com',
+            host='redis-serv.example.com',
-                    port=6379,
+            port=6379,
-                    db='0')
+            db='0')
         serv.sadd("%(id)s:jobs" % ret, ret['jid'])
         serv.set("%(jid)s:%(id)s" % ret, json.dumps(ret['return']))
         serv.sadd('jobs', ret['jid'])
@@ -349,7 +349,7 @@ infrastructure, all events seen by a salt master may be logged to one or
 more returners.
 
 To enable event logging, set the ``event_return`` configuration option in the
-master config to the returner(s) which should be designated as the handler 
+master config to the returner(s) which should be designated as the handler
 for event returns.
 
 .. note::

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

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

doc/ref/states/compiler_ordering.rst

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

doc/ref/states/parallel.rst

@@ -51,7 +51,7 @@ actually speed things up.
 To run the above state much faster make sure that the ``sleep 5`` is evaluated
 before the ``nginx`` state
 
-.. code_block:: yaml
+.. code-block:: yaml
 
     sleep 10:
       cmd.run:

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
@@ -499,7 +499,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:
@@ -839,10 +839,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        Match a :ref:`grain <grains>`, 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_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
+Before the state module can be used, it must be distributed to minions. This
-:conf_master:`file_roots` specified by the master config file. These custom
+can be done by placing them into ``salt://_states/``. They can then be
-state modules can then be distributed in a number of ways. Custom state modules
+distributed manually to minions by running :mod:`saltutil.sync_states
-are distributed when :py:func:`state.apply <salt.modules.state.apply_>` is run,
-or by executing the :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
+Any custom states which have been synced to a minion, that are named the same
-same as one of Salt's default set of states, will take the place of the default
+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
+state with the same name. Note that a state module's name defaults to one based
-(i.e. ``foo.py`` becomes state ``foo``), but that its name can be overridden
+on its filename (i.e. ``foo.py`` becomes state module ``foo``), but that its
-by using a :ref:`__virtual__ function <virtual-modules>`.
+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>`
+The ``__states__`` variable is a :ref:`Python dictionary <typesmapping>`
-containing all of the state modules. Dictionary keys are strings representing the
+containing all of the state modules. Dictionary keys are strings representing
-names of the modules and the values are the functions themselves.
+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

@@ -169,7 +169,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/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 
+CaaS has its own non-standard API , SaltStack provides a wrapper on top of this
-wrapper on top of this `API`_ with common methods with other IaaS solutions and
+API with common methods with other IaaS solutions and Public cloud providers.
-Public cloud providers. Therefore, you can use the Dimension Data
+Therefore, you can use the Dimension Data module to communicate with both the
-module to communicate with both the public and private clouds.
+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
+    In version 2015.8.0, the ``provider`` parameter in cloud provider
-    change was made to avoid confusion with the ``provider`` parameter that is used in cloud profile
+    definitions was renamed to ``driver``. This change was made to avoid
-    definitions. Cloud provider definitions now use ``driver`` to refer to the Salt cloud module that
+    confusion with the ``provider`` parameter that is used in cloud profile
-    provides the underlying functionality to connect to a cloud host, while cloud profiles continue
+    definitions. Cloud provider definitions now use ``driver`` to refer to the
-    to use ``provider`` to refer to provider configurations that you define.
+    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
 ========

doc/topics/cloud/misc.rst

@@ -25,7 +25,7 @@ This has also been tested to work with pipes, if needed:
 
 .. code-block:: yaml
 
-    script_args: | head
+    script_args: '| head'
 
 
 Selecting the File Transport

doc/topics/cloud/proxmox.rst

@@ -149,10 +149,10 @@ with their default settings listed.
 
     # The name of the image, from ``salt-cloud --list-images proxmox``
     image: local:vztmpl/ubuntu-12.04-standard_12.04-1_amd64.tar.gz
-    
+
     # Whether or not to verify the SSL cert on the Proxmox host
     verify_ssl: False
-    
+
     # Network interfaces, netX
     net0: name=eth0,bridge=vmbr0,ip=dhcp
 
@@ -172,7 +172,7 @@ QEMU profile file (for a new VM):
 
     # Technology used to create the VM ('qemu', 'openvz'(on Proxmox <4.x) or 'lxc'(on Proxmox 4.x+))
     technology: qemu
- 
+
     # Proxmox node name
     host: node_name
 
@@ -187,7 +187,7 @@ QEMU profile file (for a new VM):
 
     # OS Type enum (other / wxp / w2k / w2k3 / w2k8 / wvista / win7 / win8 / l24 / l26 / solaris)
     ostype: win7
-    
+
     # Hard disk location
     sata0: <location>:<size>, format=<qcow2/vmdk/raw>, size=<size>GB #Example: local:120,format=qcow2,size=120GB
 
@@ -231,7 +231,7 @@ QEMU profile file (for a clone):
 
     # Technology used to create the VM ('qemu' or 'lxc')
     technology: qemu
- 
+
     # Proxmox node name
     host: node_name
 
@@ -244,5 +244,11 @@ QEMU profile file (for a clone):
 More information can be found on Proxmox API under the 'POST' method of /nodes/{node}/qemu/{vmid}/clone
 
 .. note::
-    The Proxmox API offers a lot more options and parameters, which are not yet supported by this salt-cloud 'overlay'. Feel free to add your contribution by forking the github repository and modifying  the following file: salt/salt/cloud/clouds/proxmox.py
+    The Proxmox API offers a lot more options and parameters, which are not yet
-    An easy way to support more parameters for VM creation would be to add the names of the optional parameters in the 'create_nodes(vm_)' function, under the 'qemu' technology. But it requires you to dig into the code ...
+    supported by this salt-cloud 'overlay'. Feel free to add your contribution
+    by forking the github repository and modifying  the following file:
+    ``salt/cloud/clouds/proxmox.py``
+
+    An easy way to support more parameters for VM creation would be to add the
+    names of the optional parameters in the 'create_nodes(vm\_)' function, under
+    the 'qemu' technology. But it requires you to dig into the code ...

doc/topics/cloud/releases/0.8.5.rst

@@ -149,7 +149,7 @@ This has also been tested to work with pipes, if needed:
 
 .. code-block:: yaml
 
-    script_args: | head
+    script_args: '| head'
 
 Remove Old SSH Keys
 ===================

doc/topics/cloud/virtualbox.rst

@@ -28,8 +28,6 @@ The Virtualbox cloud module just needs to use the virtualbox driver for now. Vir
        driver: virtualbox
 
 
-.. _vmware-cloud-profile:
-
 Profiles
 ========
 

doc/topics/cloud/vmware.rst

@@ -210,7 +210,7 @@ Set up an initial profile at ``/etc/salt/cloud.profiles`` or
 
       hardware_version: 10
       image: centos64Guest
-      
+
       #For Windows VM
       win_username: Administrator
       win_password: administrator
@@ -231,13 +231,14 @@ Set up an initial profile at ``/etc/salt/cloud.profiles`` or
     the current VM/template\'s vCPU count is used.
 
 ``cores_per_socket``
-    .. versionadded:: 2016.11.0
     Enter the number of cores per vCPU that you want the VM/template to have. If not specified,
-    this will default to 1. 
+    this will default to 1.
-    
-    .. note::
 
-        Cores per socket should be less than or equal to the total number of vCPUs assigned to the VM/template.
+    .. note::
+        Cores per socket should be less than or equal to the total number of
+        vCPUs assigned to the VM/template.
+
+    .. versionadded:: 2016.11.0
 
 ``memory``
     Enter the memory size (in MB or GB) that you want the VM/template to have. If
@@ -505,31 +506,31 @@ Set up an initial profile at ``/etc/salt/cloud.profiles`` or
 
 ``win_username``
     Specify windows vm administrator account.
-        
+
     .. note::
-    
+
     	Windows template should have "administrator" account.
 
 ``win_password``
     Specify windows vm administrator account password.
-    
+
     .. note::
 
-        During network configuration (if network specified), it is used to specify new administrator password for the machine. 
+        During network configuration (if network specified), it is used to specify new administrator password for the machine.
 
 ``win_organization_name``
     Specify windows vm user's organization. Default organization name is Organization
    	VMware vSphere documentation:
-	
+
     https://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/vim.vm.customization.UserData.html
 
 ``win_user_fullname``
     Specify windows vm user's fullname. Default fullname is "Windows User"
    	VMware vSphere documentation:
-	
+
     https://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/vim.vm.customization.UserData.html
 
-``plain_text``    	
+``plain_text``
 	Flag to specify whether or not the password is in plain text, rather than encrypted.
 	VMware vSphere documentation:
 
@@ -589,7 +590,7 @@ Example to reconfigure the memory and number of vCPUs:
       clonefrom: 'test-vm'
 
       memory: 16GB
-      num_cpus: 8 
+      num_cpus: 8
 
 
 Cloning a Template

doc/topics/cloud/windows.rst

@@ -60,7 +60,7 @@ If supported by the cloud provider, a PowerShell script may be used to open up
 this port automatically, using the cloud provider's `userdata`. The following
 script would open up port 445, and apply the changes:
 
-.. code-block:: powershell
+.. code-block:: text
 
     <powershell>
     New-NetFirewallRule -Name "SMB445" -DisplayName "SMB445" -Protocol TCP -LocalPort 445
@@ -113,7 +113,7 @@ enabled in your userdata. By default EC2 Windows images only have insecure HTTP
 enabled. To enable HTTPS and basic authentication required by pywinrm consider
 the following userdata example:
 
-.. code-block:: powershell
+.. code-block:: text
 
     <powershell>
     New-NetFirewallRule -Name "SMB445" -DisplayName "SMB445" -Protocol TCP -LocalPort 445

doc/topics/configuration/index.rst

@@ -7,6 +7,7 @@ secure and troubleshoot, and how to perform many other administrative tasks.
 
 .. toctree::
     :maxdepth: 1
+    :glob:
 
     ../../ref/configuration/master
     ../../ref/configuration/minion
@@ -18,6 +19,7 @@ secure and troubleshoot, and how to perform many other administrative tasks.
     ../jobs/job_cache
     ../jobs/external_cache
     ../../ref/configuration/logging/index
+    ../../ref/configuration/logging/handlers/*
     ../../ref/file_server/index
     ../tutorials/gitfs
     ../tutorials/minionfs

doc/topics/development/contributing.rst

@@ -21,11 +21,21 @@ SaltStack has its own coding style guide that informs contributors on various co
 approaches. Please review the :ref:`Salt Coding Style <coding-style>` documentation
 for information about Salt's particular coding patterns.
 
-Within the :ref:`Salt Coding Style <coding-style>` documentation, there is a section
+Within the :ref:`Salt Coding Style <coding-style>` documentation, there is a
-about running Salt's ``.pylintrc`` file. SaltStack recommends running the ``.pylintrc``
+section about running Salt's ``.testing.pylintrc`` file. SaltStack recommends
-file on any files you are changing with your code contribution before submitting a
+running the ``.testing.pylintrc`` file on any files you are changing with your
-pull request to Salt's repository. Please see the :ref:`Linting<pylint-instructions>`
+code contribution before submitting a pull request to Salt's repository. Please
-documentation for more information.
+see the :ref:`Linting<pylint-instructions>` documentation for more information.
+
+.. note::
+
+    There are two pylint files in the ``salt`` directory. One is the
+    ``.pylintrc`` file and the other is the ``.testing.pylintrc`` file. The
+    tests that run in Jenkins against GitHub Pull Requests use
+    ``.testing.pylintrc``. The ``testing.pylintrc`` file is a little less
+    strict than the ``.pylintrc`` and is used to make it easier for contributors
+    to submit changes. The ``.pylintrc`` file can be used for linting, but the
+    ``testing.pylintrc`` is the source of truth when submitting pull requests.
 
 
 .. _github-pull-request:

doc/topics/development/conventions/formulas.rst

@@ -226,7 +226,7 @@ Style
 Maintainability, readability, and reusability are all marks of a good Salt sls
 file. This section contains several suggestions and examples.
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     # Deploy the stable master branch unless version overridden by passing
     # Pillar at the CLI or via the Reactor.
@@ -448,7 +448,7 @@ lookups.
 
 Below is a simple example of a readable loop:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% for user in salt.pillar.get('list_of_users', []) %}
 
@@ -465,7 +465,7 @@ Readability suffers and the correct YAML indentation is difficult to see in the
 surrounding visual noise. Parametrization (discussed below) and variables are
 both useful techniques to avoid this. For example:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {# ---- Bad example ---- #}
 
@@ -506,7 +506,7 @@ easily combined and merged. And they can be directly serialized into YAML which
 is often easier than trying to create valid YAML through templating. For
 example:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {# ---- Bad example ---- #}
 
@@ -600,7 +600,10 @@ example is a state tree of two sls files, one simple and one complicated.
 
     common_users:
       user.present:
-        - names: [larry, curly, moe]
+        - names:
+          - larry
+          - curly
+          - moe
 
 ``/srv/salt/roles_configuration``:
 
@@ -652,7 +655,7 @@ above).
 
 Macros are useful for creating reusable, parameterized states. For example:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% macro user_state(state_id, user_name, shell='/bin/bash', groups=[]) %}
     {{ state_id }}:
@@ -672,7 +675,7 @@ example, the following macro could be used to write a php.ini config file:
 
 ``/srv/salt/php.sls``:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     php_ini:
       file.managed:
@@ -769,7 +772,7 @@ syntax for referencing a value is a normal dictionary lookup in Jinja, such as
 Values defined in the map file can be fetched for the current platform in any
 state file using the following syntax:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% from "mysql/map.jinja" import mysql with context %}
 
@@ -963,7 +966,7 @@ XML.)
 
 ``/srv/salt/tomcat/server_xml.sls``:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% import_yaml 'tomcat/defaults.yaml' as server_xml_defaults %}
     {% set server_xml_final_values = salt.pillar.get(
@@ -998,7 +1001,7 @@ example:
 
 ``/srv/salt/app/deploy.sls``:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {# Load the map file. #}
     {% import_yaml 'app/defaults.yaml' as app_defaults %}
@@ -1057,7 +1060,7 @@ The following is a best-practice example for a reusable Apache formula. (This
 skips platform-specific options for brevity. See the full
 :formula_url:`apache-formula` for more.)
 
-.. code-block:: yaml
+.. code-block:: text
 
     # apache/init.sls
     apache:

doc/topics/development/conventions/style.rst

@@ -22,21 +22,31 @@ improve Salt)!!
 Linting
 =======
 
-Most Salt style conventions are codified in Salt's ``.pylintrc`` file. Salt's
+Most Salt style conventions are codified in Salt's ``.testing.pylintrc`` file.
-pylint file has two dependencies: pylint_ and saltpylint_. You can install
+Salt's pylint file has two dependencies: pylint_ and saltpylint_. You can
-these dependencies with ``pip``:
+install these dependencies with ``pip``:
 
 .. code-block:: bash
 
     pip install pylint
     pip install saltpylint
 
-The ``.pylintrc`` file is found in the root of the Salt project and can be passed
+The ``.testing.pylintrc`` file is found in the root of the Salt project and can
-as an argument to the pylint_ program as follows:
+be passed as an argument to the pylint_ program as follows:
 
 .. code-block:: bash
 
-    pylint --rcfile=/path/to/salt/.pylintrc salt/dir/to/lint
+    pylint --rcfile=/path/to/salt/.testing.pylintrc salt/dir/to/lint
+
+.. note::
+
+    There are two pylint files in the ``salt`` directory. One is the
+    ``.pylintrc`` file and the other is the ``.testing.pylintrc`` file. The
+    tests that run in Jenkins against GitHub Pull Requests use
+    ``.testing.pylintrc``. The ``testing.pylintrc`` file is a little less
+    strict than the ``.pylintrc`` and is used to make it easier for contributors
+    to submit changes. The ``.pylintrc`` file can be used for linting, but the
+    ``testing.pylintrc`` is the source of truth when submitting pull requests.
 
 .. _pylint: http://www.pylint.org
 .. _saltpylint: https://github.com/saltstack/salt-pylint

doc/topics/development/extend/index.rst

@@ -12,38 +12,38 @@ You can use Salt Extend to quickly create templated modules for adding new behav
 Salt Extend takes a template directory and merges it into a SaltStack source code directory.
 
 Command line usage
-~~~~~~~~~~~~~~~~~~
+------------------
 
 *See* :ref:`salt-extend <salt-extend>`
 
 Choosing a template
-~~~~~~~~~~~~~~~~~~~
+-------------------
 
 The following templates are available:
 
 module
-^^^^^^
+******
 
 Creates a new execution module within salt/modules/{{module_name}}.py
 
 module_unit
-^^^^^^^^^^^
+***********
 
 Creates a new execution module unit test suite within tests/unit/modules/test_{{module_name}}.py
 
 state
-^^^^^
+*****
 
 Creates a new state module within salt/states/{{module_name}}.py
 
 state_unit
-^^^^^^^^^^
+**********
 
 Creates a new state module unit test suite within tests/unit/states/test_{{module_name}}.py
 
 
 Adding templates
-~~~~~~~~~~~~~~~~
+----------------
 
 1. Create a directory under <src>/templates
 2. Create a file ``template.yml`` containing properties for
@@ -51,12 +51,12 @@ Adding templates
  * ``description`` - a description of the template
  * ``questions`` - a collection of additional questions to ask the user, the name of the item will
    be used as the key in the context dictionary within the jinja template.
-   
+
    * ``question`` - The question to ask the user, as a string
    * ``default`` - (optional) the default value, can contain Jinja2 template syntax and has access to the default context properties
 
 Example template.yml
-^^^^^^^^^^^^^^^^^^^^
+********************
 
 .. code-block:: yaml
 
@@ -71,19 +71,19 @@ Example template.yml
 3. Create the files within <src>/templates/<your template> to match the target
 
 .. note::
-    
+
     File names can contain Jinja 2 template syntax, e.g. *'{{module_name}}.py}}'*
 
 Example file in the template directory
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+**************************************
 
 .. code-block:: python
 
     print('Hello {{module_name}}')
     __virtual__ = '{{__virtual_name__}}'
-    
+
 Default context properties
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+**************************
 
 The default context provides the following properties
 
@@ -97,10 +97,10 @@ The default context provides the following properties
 As well as any additional properties entered from the questions section of ``template.yml``
 
 API
-~~~
+---
 
 salt.utils.extend module
-========================
+************************
 
 .. automodule:: salt.utils.extend
     :members:

doc/topics/development/index.rst

@@ -8,7 +8,7 @@ Developing Salt
 
     *
     extend/index
-    tests/index
+    tests/*
     raet/index
     git/index
     conventions/index

doc/topics/development/labels.rst

@@ -4,98 +4,105 @@
 GitHub Labels and Milestones
 ============================
 
-SaltStack uses several label categories, as well as milestones, to triage incoming issues and pull requests in the
+SaltStack uses several label categories, as well as milestones, to triage
-GitHub issue tracker.  Labels are used to sort issues by type, priority, severity, status, functional area, functional
+incoming issues and pull requests in the GitHub issue tracker.  Labels are used
-group, and targeted release and pull requests by status, functional area, functional group, type of change, and test
+to sort issues by type, priority, severity, status, functional area, functional
-status.  Milestones are used to indicate whether an issue is fully triaged or is scheduled to be fixed by SaltStack in
+group, and targeted release and pull requests by status, functional area,
-an upcoming sprint.
+functional group, type of change, and test status.  Milestones are used to
+indicate whether an issue is fully triaged or is scheduled to be fixed by
+SaltStack in an upcoming sprint.
 
 Milestones
 ==========
 
-All issues are assigned to a milestone, whereas pull requests are almost never assigned to a milestone as the mean
+All issues are assigned to a milestone, whereas pull requests are almost never
-lifetime of pull requests is short enough that there is no need to track them temporally.
+assigned to a milestone as the mean lifetime of pull requests is short enough
+that there is no need to track them temporally.
 
-SaltStack uses milestones to indicate which issues are blocked on submitter or upstream actions, are approved, or are
+SaltStack uses milestones to indicate which issues are blocked on submitter or
-scheduled to be fixed or implemented in an upcoming sprint.  If an issue is not attached to a sprint milestone, you are
+upstream actions, are approved, or are scheduled to be fixed or implemented in
-welcome to work on it at your own desire and convenience.  If it is attached to a sprint milestone and you have already
+an upcoming sprint.  If an issue is not attached to a sprint milestone, you are
-begun working on it or have a solution in mind or have other ideas related to the issue, you are encouraged to
+welcome to work on it at your own desire and convenience.  If it is attached to
-coordinate with the assignee via the GitHub issue tracker to create the best possible solution or implementation.
+a sprint milestone and you have already begun working on it or have a solution
+in mind or have other ideas related to the issue, you are encouraged to
+coordinate with the assignee via the GitHub issue tracker to create the best
+possible solution or implementation.
 
-``Approved``
+- ``Approved`` - The issue has been validated and has all necessary information.
-    The issue has been validated and has all necessary information.
 
-``Blocked``
+- ``Blocked`` - The issue is waiting on actions by parties outside of
-    The issue is waiting on actions by parties outside of SaltStack, such as receiving more information from the
+  SaltStack, such as receiving more information from the submitter or
-    submitter or resolution of an upstream issue.  This milestone is usually applied in conjunction with the labels
+  resolution of an upstream issue.  This milestone is usually applied in
-    ``Info Needed``, ``Question``, ``Expected Behavior``, ``Won't Fix For Now``, or ``Upstream Bug``.
+  conjunction with the labels ``Info Needed``, ``Question``, ``Expected
+  Behavior``, ``Won't Fix For Now``, or ``Upstream Bug``.
 
-``Under Review``
+- ``Under Review`` - The issue is having further validation done by a SaltStack
-    The issue is having further validation done by a SaltStack engineer.
+  engineer.
 
-``<Sprint>``
+- ``<Sprint>`` - The issue is being actively worked on by a SaltStack engineer.
-    The issue is being actively worked on by a SaltStack engineer.  Sprint milestones names are constructed from the
+  Sprint milestones names are constructed from the chemical symbol of the next
-    chemical symbol of the next release's codename and the number of sprints until that release is made.  For example,
+  release's codename and the number of sprints until that release is made.  For
-    if the next release codename is ``Neon`` and there are five sprints until that release, the corresponding sprint
+  example, if the next release codename is ``Neon`` and there are five sprints
-    milestone will be called ``Ne 5``.  See :ref:`<version-numbers>` for a discussion of Salt's release
+  until that release, the corresponding sprint milestone will be called ``Ne
-    codenames.
+  5``.  See :ref:`here <version-numbers>` for a discussion of Salt's release
+  codenames.
 
 Labels
 ======
 
-Labels are used to sort and describe issues and pull requests.  Some labels are usually reserved for one or the other,
+Labels are used to sort and describe issues and pull requests.  Some labels are
-though most labels may be applied to both.
+usually reserved for one or the other, though most labels may be applied to
+both.
 
-New issues will receive at least one label and a milestone, and new pull requests will receive at least one label.
+New issues will receive at least one label and a milestone, and new pull
-Except for the :ref:`functional area <functional-area-labels>` and :ref:`functional group <functional-group-labels>`
+requests will receive at least one label.  Except for the :ref:`functional area
-label categories, issues will generally receive only up to one label per category.
+<functional-area-labels>` and :ref:`functional group <functional-group-labels>`
+label categories, issues will generally receive only up to one label per
+category.
 
 Type
 ----
 
-Issues are categorized into one of several types.  Type labels are almost never used for pull requests.  GitHub treats
+Issues are categorized into one of several types.  Type labels are almost never
-pull requests like issues in many ways, so a pull request could be considered an issue with an implicit ``Pull Request``
+used for pull requests.  GitHub treats pull requests like issues in many ways,
-type label applied.
+so a pull request could be considered an issue with an implicit ``Pull
+Request`` type label applied.
 
-``Feature``
+- ``Feature`` - The issue is a request for new functionality including changes,
-    The issue is a request for new functionality including changes, enhancements, refactors, etc.
+  enhancements, refactors, etc.
 
-``Bug``
+- ``Bug`` - The issue documents broken, incorrect, or confusing behavior.  This
-    The issue documents broken, incorrect, or confusing behavior.  This label is always accompanied by a :ref:`severity
+  label is always accompanied by a :ref:`severity label <bug-severity-labels>`.
-    label <bug-severity-labels>`.
 
-``Duplicate``
+- ``Duplicate`` - The issue is a duplicate of another feature request or bug
-    The issue is a duplicate of another feature request or bug report.
+  report.
 
-``Upstream Bug``
+- ``Upstream Bug`` - The issue is a result of an upstream issue.
-    The issue is a result of an upstream issue.
 
-``Question``
+- ``Question`` - The issue is more of a question than a request for new
-    The issue is more of a question than a request for new features or a report of broken features, but can sometimes
+  features or a report of broken features, but can sometimes lead to further
-    lead to further discussion or changes of confusing or incongruous behavior or documentation.
+  discussion or changes of confusing or incongruous behavior or documentation.
 
-``Expected Behavior``
+- ``Expected Behavior`` - The issue is a bug report of intended functionality.
-    The issue is a bug report of intended functionality.
 
 Priority
 --------
 
-An issue's priority is relative to its :ref:`functional area <functional-area-labels>`.  If a bug report, for example,
+An issue's priority is relative to its :ref:`functional area
-about ``gitfs`` indicates that all users of ``gitfs`` will encounter this bug, then a ``P1`` label will be applied, even
+<functional-area-labels>`.  If a bug report, for example, about ``gitfs``
-though users who are not using ``gitfs`` will not encounter the bug.  If a feature is requested by many users, it may be
+indicates that all users of ``gitfs`` will encounter this bug, then a ``P1``
-given a high priority.
+label will be applied, even though users who are not using ``gitfs`` will not
+encounter the bug.  If a feature is requested by many users, it may be given a
+high priority.
 
-``P1``
+- ``P1`` - The issue will be seen by all users.
-    The issue will be seen by all users.
 
-``P2``
+- ``P2`` - The issue will be seen by most users.
-    The issue will be seen by most users.
 
-``P3``
+- ``P3`` - The issue will be seen by about half of users.
-    The issue will be seen by about half of users.
 
-``P4``
+- ``P4`` - The issue will not be seen by most users.  Usually the issue is a
-    The issue will not be seen by most users.  Usually the issue is a very specific use case or corner case.
+  very specific use case or corner case.
 
 .. _bug-severity-labels:
 
@@ -104,196 +111,219 @@ Severity
 
 Severity labels are almost always only applied to issues labeled ``Bug``.
 
-``Blocker``
+- ``Blocker`` - The issue is blocking an impending release.
-    The issue is blocking an impending release.
 
-``Critical``
+- ``Critical`` - The issue causes data loss, crashes or hangs salt processes,
-    The issue causes data loss, crashes or hangs salt processes, makes the system unresponsive, etc.
+  makes the system unresponsive, etc.
 
-``High Severity``
+- ``High Severity`` - The issue reports incorrect functionality, bad
-    The issue reports incorrect functionality, bad functionality, a confusing user experience, etc.
+  functionality, a confusing user experience, etc.
 
-``Medium Severity``
+- ``Medium Severity`` - The issue reports cosmetic items, formatting, spelling,
-    The issue reports cosmetic items, formatting, spelling, colors, etc.
+  colors, etc.
 
 .. _functional-area-labels:
 
 Functional Area
 ---------------
 
-Many major components of Salt have corresponding GitHub labels.  These labels are applied to all issues and pull
+Many major components of Salt have corresponding GitHub labels.  These labels
-requests as is reasonably appropriate.  They are useful in organizing issues and pull requests according to the source
+are applied to all issues and pull requests as is reasonably appropriate.  They
-code relevant to issues or the source code changed by pull requests.
+are useful in organizing issues and pull requests according to the source code
+relevant to issues or the source code changed by pull requests.
 
-* ``Execution Module``
+- ``Execution Module``
-* ``File Servers``
+- ``File Servers``
-* ``Grains``
+- ``Grains``
-* ``Multi-Master``
+- ``Multi-Master``
-* ``Packaging``  Related to packaging of Salt, not Salt's support for package management.
+- ``Packaging``  Related to packaging of Salt, not Salt's support for package management.
-* ``Pillar``
+- ``Pillar``
-* ``RAET``
+- ``RAET``
-* ``Returners``
+- ``Returners``
-* ``Runners``
+- ``Runners``
-* ``SPM``
+- ``SPM``
-* ``Salt-API``
+- ``Salt-API``
-* ``Salt-Cloud``
+- ``Salt-Cloud``
-* ``Salt-SSH``
+- ``Salt-SSH``
-* ``Salt-Syndic``
+- ``Salt-Syndic``
-* ``State Module``
+- ``State Module``
-* ``Tests``
+- ``Tests``
-* ``Transport``
+- ``Transport``
-* ``Windows``
+- ``Windows``
-* ``ZMQ``
+- ``ZMQ``
 
 .. _functional-group-labels:
 
 Functional Group
 ----------------
 
-These labels sort issues and pull requests according to the internal SaltStack engineering teams.
+These labels sort issues and pull requests according to the internal SaltStack
+engineering teams.
 
-``Core``
+- ``Core`` - The issue or pull request relates to code that is central or
-    The issue or pull request relates to code that is central or existential to Salt itself.
+  existential to Salt itself.
 
-``Platform``
+- ``Platform`` - The issue or pull request relates to support and integration
-    The issue or pull request relates to support and integration with various platforms like traditional operating
+  with various platforms like traditional operating systems as well as
-    systems as well as containers, platform-based utilities like filesystems, command schedulers, etc., and
+  containers, platform-based utilities like filesystems, command schedulers,
-    system-based applications like webservers, databases, etc.
+  etc., and system-based applications like webservers, databases, etc.
 
-``RIoT``
+- ``RIoT`` - The issue or pull request relates to support and integration with
-    The issue or pull request relates to support and integration with various abstract systems like cloud providers,
+  various abstract systems like cloud providers, hypervisors, API-based
-    hypervisors, API-based services, etc.
+  services, etc.
 
-``Console``
+- ``Console`` - The issue or pull request relates to the SaltStack enterprise
-    The issue or pull request relates to the SaltStack enterprise console.
+  console.
 
-``Documentation``
+- ``Documentation`` - The issue or pull request relates to documentation.
-    The issue or pull request relates to documentation.
 
 Status
 ------
 
-Status labels are used to define and track the state of issues and pull requests.  Not all potential statuses correspond
+Status labels are used to define and track the state of issues and pull
-to a label, but some statuses are common enough that labels have been created for them.  If an issue has not been moved
+requests.  Not all potential statuses correspond to a label, but some statuses
-beyond the ``Blocked`` milestone, it is very likely that it will only have a status label.
+are common enough that labels have been created for them.  If an issue has not
+been moved beyond the ``Blocked`` milestone, it is very likely that it will
+only have a status label.
 
-``Bugfix - back-port``
+- ``Bugfix - back-port`` The pull request needs to be back-ported to an older
-    The pull request needs to be back-ported to an older release branch.  This is done by :ref:`recreating the pull
+  release branch.  This is done by :ref:`recreating the pull request
-    request <backporting-pull-requests>` against that branch.  Once the back-port is completed, this label is replaced
+  <backporting-pull-requests>` against that branch.  Once the back-port is
-    with a ``Bugfix - [Done] back-ported`` label.  Normally, new features should go into the develop and bug fixes into
+  completed, this label is replaced with a ``Bugfix - [Done] back-ported``
-    the oldest supported release branch, see :ref:`<which-salt-branch>`.
+  label.  Normally, new features should go into the develop and bug fixes into
+  the oldest supported release branch, see :ref:`here <which-salt-branch>`.
 
-``Bugfix - [Done] back-ported``
+- ``Bugfix - [Done] back-ported`` - The pull request has been back-ported to an
-    The pull request has been back-ported to an older branch.
+  older branch.
 
-``Cannot Reproduce``
+- ``Cannot Reproduce`` - The issue is a bug and has been reviewed by a
-    The issue is a bug and has been reviewed by a SaltStack engineer, but it cannot be replicated with the provided
+  SaltStack engineer, but it cannot be replicated with the provided information
-    information and context.  Those involved with the bug will need to work through additional ideas until the bug can
+  and context.  Those involved with the bug will need to work through
-    be isolated and verified.
+  additional ideas until the bug can be isolated and verified.
 
-``Confirmed``
+- ``Confirmed`` - The issue is a bug and has been confirmed by a SaltStack
-    The issue is a bug and has been confirmed by a SaltStack engineer, who often documents a minimal working example
+  engineer, who often documents a minimal working example that reproduces the
-    that reproduces the bug.
+  bug.
 
-``Fixed Pending Verification``
+- ``Fixed Pending Verification`` - The issue is a bug and has been fixed by one
-    The issue is a bug and has been fixed by one or more pull requests, which should link to the issue.  Closure of the
+  or more pull requests, which should link to the issue.  Closure of the issue
-    issue is contingent upon confirmation of resolution from the submitter.  If the submitter reports a negative
+  is contingent upon confirmation of resolution from the submitter.  If the
-    confirmation, this label is removed.  If no response is given after a few weeks, then the issue will be assumed
+  submitter reports a negative confirmation, this label is removed.  If no
-    fixed and closed.
+  response is given after a few weeks, then the issue will be assumed fixed and
+  closed.
 
-``Info Needed``
+- ``Info Needed`` - The issue needs more information before it can be verified
-    The issue needs more information before it can be verified and resolved.  For a feature request this may include a
+  and resolved.  For a feature request this may include a description of the
-    description of the use cases.  Almost all bug reports need to include at least the versions of salt and its
+  use cases.  Almost all bug reports need to include at least the versions of
-    dependencies, the system type and version, commands used, debug logs, error messages, and relevant configs.
+  salt and its dependencies, the system type and version, commands used, debug
+  logs, error messages, and relevant configs.
 
-``Pending Changes``
+- ``Pending Changes`` - The pull request needs additional changes before it can
-    The pull request needs additional changes before it can be merged.
+  be merged.
 
-``Pending Discussion``
+- ``Pending Discussion`` - The issue or pull request needs more discussion
-    The issue or pull request needs more discussion before it can be closed or merged.  The status of the issue or pull
+  before it can be closed or merged.  The status of the issue or pull request
-    request is not clear or apparent enough for definite action to be taken, or additional input from SaltStack, the
+  is not clear or apparent enough for definite action to be taken, or
-    submitter, or another party has been requested.
+  additional input from SaltStack, the submitter, or another party has been
+  requested.
 
-    If the issue is not a pull request, once the discussion has arrived at a cogent conclusion, this label will be
+  If the issue is not a pull request, once the discussion has arrived at a
-    removed and the issue will be accepted.  If it is a pull request, the results of the discussion may require
+  cogent conclusion, this label will be removed and the issue will be accepted.
-    additional changes and thus, a ``Pending Changes`` label.
+  If it is a pull request, the results of the discussion may require additional
+  changes and thus, a ``Pending Changes`` label.
 
-``Won't Fix for Now``
+- ``Won't Fix for Now`` - The issue is legitimate, but it is not something the
-    The issue is legitimate, but it is not something the SaltStack team is currently able or willing to fix or
+  SaltStack team is currently able or willing to fix or implement.  Issues
-    implement.  Issues having this label may be revisited in the future.
+  having this label may be revisited in the future.
 
 Type of Change
 ~~~~~~~~~~~~~~
 
-Every pull request should receive a change label.  These labels measure the quantity of change as well as the
+Every pull request should receive a change label.  These labels measure the
-significance of the change.  The amount of change and the importance of the code area changed are considered, but often
+quantity of change as well as the significance of the change.  The amount of
-the depth of secondary code review required and the potential repercussions of the change may also advise the label
+change and the importance of the code area changed are considered, but often
-choice.
+the depth of secondary code review required and the potential repercussions of
+the change may also advise the label choice.
 
-Core code areas include: state compiler, crypto engine, master and minion and syndic daemons, transport, pillar
+Core code areas include: state compiler, crypto engine, master and minion and
-rendering, loader, transport layer, event system, salt.utils, client, cli, logging, netapi, runner engine, templating
+syndic daemons, transport, pillar rendering, loader, transport layer, event
-engine, top file compilation, file client, file server, mine, salt-ssh, test runner, etc.
+system, salt.utils, client, cli, logging, netapi, runner engine, templating
+engine, top file compilation, file client, file server, mine, salt-ssh, test
+runner, etc.
 
-Non-core code usually constitutes the specific set of plugins for each of the several plugin layers of Salt: execution
+Non-core code usually constitutes the specific set of plugins for each of the
-modules, states, runners, returners, clouds, etc.
+several plugin layers of Salt: execution modules, states, runners, returners,
+clouds, etc.
 
-``Minor Change``
+- ``Minor Change``
-    * Less than 64 lines changed, or
+
-    * Less than 8 core lines changed
+  * Less than 64 lines changed, or
-``Medium Change``
+
-    * Less than 256 lines changed, or
+  * Less than 8 core lines changed
-    * Less than 64 core lines changed
+
-``Master Change``
+- ``Medium Change``
-    * More than 256 lines changed, or
+
-    * More than 64 core lines changed
+  * Less than 256 lines changed, or
-``Expert Change``
+
-    * Needs specialized, in-depth review
+  * Less than 64 core lines changed
+
+- ``Master Change``
+
+  * More than 256 lines changed, or
+
+  * More than 64 core lines changed
+
+- ``Expert Change``
+
+  * Needs specialized, in-depth review
 
 Test Status
 -----------
 
-These labels relate to the status of the automated tests that run on pull requests.  If the tests on a pull request fail
+These labels relate to the status of the automated tests that run on pull
-and are not overridden by one of these labels, the pull request submitter needs to update the code and/or tests so that
+requests.  If the tests on a pull request fail and are not overridden by one of
-the tests pass and the pull request can be merged.
+these labels, the pull request submitter needs to update the code and/or tests
+so that the tests pass and the pull request can be merged.
 
-``Lint``
+- ``Lint`` - The pull request has passed all tests except for the code lint
-    The pull request has passed all tests except for the code lint checker.
+  checker.
 
-``Tests Passed``
+- ``Tests Passed`` - The pull request has passed all tests even though some
-    The pull request has passed all tests even though some test results are negative.  Sometimes the automated testing
+  test results are negative.  Sometimes the automated testing infrastructure
-    infrastructure will encounter internal errors unrelated to the code change in the pull request that cause test runs
+  will encounter internal errors unrelated to the code change in the pull
-    to fail.  These errors can be caused by cloud host and network issues and also Jenkins issues like erroneously
+  request that cause test runs to fail.  These errors can be caused by cloud
-    accumulating workspace artifacts, resource exhaustion, and bugs that arise from long running Jenkins processes.
+  host and network issues and also Jenkins issues like erroneously accumulating
+  workspace artifacts, resource exhaustion, and bugs that arise from long
+  running Jenkins processes.
 
 Other
 -----
 
-These labels indicate miscellaneous issue types or statuses that are common or important enough to be tracked and sorted
+These labels indicate miscellaneous issue types or statuses that are common or
-with labels.
+important enough to be tracked and sorted with labels.
 
-``Awesome``
+- ``Awesome`` - The pull request implements an especially well crafted
-    The pull request implements an especially well crafted solution, or a very difficult but necessary change.
+  solution, or a very difficult but necessary change.
 
-``Help Wanted``
+- ``Help Wanted`` - The issue appears to have a simple solution.  Issues having
-    The issue appears to have a simple solution.  Issues having this label
+  this label should be a good starting place for new contributors to Salt.
-    should be a good starting place for new contributors to Salt.
 
-``Needs Testcase``
+- ``Needs Testcase`` - The issue or pull request relates to a feature that
-    The issue or pull request relates to a feature that needs test coverage.  The pull request containing the tests
+  needs test coverage.  The pull request containing the tests should reference
-    should reference the issue or pull request having this label, whereupon the label should be removed.
+  the issue or pull request having this label, whereupon the label should be
+  removed.
 
-``Regression``
+- ``Regression`` - The issue is a bug that breaks functionality known to work
-    The issue is a bug that breaks functionality known to work in previous releases.
+  in previous releases.
 
-``Story``
+- ``Story`` - The issue is used by a SaltStack engineer to track progress on
-    The issue is used by a SaltStack engineer to track progress on multiple related issues in a single place.
+  multiple related issues in a single place.
 
-``Stretch``
+- ``Stretch`` - The issue is an optional goal for the current sprint but may
-    The issue is an optional goal for the current sprint but may not be delivered.
+  not be delivered.
 
-``ZD``
+- ``ZD`` - The issue is related to a Zendesk customer support ticket.
-    The issue is related to a Zendesk customer support ticket.
 
-``<Release>``
+- ``<Release>`` - The issue is scheduled to be implemented by ``<Release>``.
-    The issue is scheduled to be implemented by ``<Release>``.  See :ref:`<version-numbers>` for a
+  See :ref:`here <version-numbers>` for a discussion of Salt's release
-    discussion of Salt's release codenames.
+  codenames.

doc/topics/development/tutorial.rst

@@ -34,7 +34,7 @@ Clone
 In your CLI, navigate to the directory into which you want clone the Salt
 codebase and submit the following command:
 
-.. code-block:: shell
+.. code-block:: bash
 
     $ git clone https://github.com/<my_account>/salt.git
 
@@ -42,7 +42,7 @@ where ``<my_account>`` is the name of your GitHub account.  After the clone has
 completed, add SaltStack as a second remote and fetch any changes from
 ``upstream``.
 
-.. code-block:: shell
+.. code-block:: bash
 
     $ cd salt
     $ git remote add upstream https://github.com/saltstack/salt.git
@@ -53,7 +53,7 @@ the default branch for the SaltStack GitHub project.  This branch needs to
 track ``upstream/develop`` so that we will get all upstream changes when they
 happen.
 
-.. code-block:: shell
+.. code-block:: bash
 
     $ git checkout develop
     $ git branch --set-upstream-to upstream/develop
@@ -65,7 +65,7 @@ Fetch
 Fetch any ``upstream`` changes on the ``develop`` branch and sync them to your
 local copy of the branch with a single command:
 
-.. code-block:: shell
+.. code-block:: bash
 
     $ git pull --rebase
 
@@ -87,7 +87,7 @@ updated.  I'll select the ``alternatives`` module.
 Create a new branch off from ``develop``.  Be sure to name it something short
 and descriptive.
 
-.. code-block:: shell
+.. code-block:: bash
 
     $ git checkout -b virt_ret
 
@@ -97,10 +97,13 @@ Edit
 
 Edit the file you have selected, and verify that the changes are correct.
 
-.. code-block:: shell
+.. code-block:: bash
 
     $ vim salt/modules/alternatives.py
     $ git diff
+
+.. code-block:: diff
+
     diff --git a/salt/modules/alternatives.py b/salt/modules/alternatives.py
     index 1653e5f..30c0a59 100644
     --- a/salt/modules/alternatives.py
@@ -122,7 +125,7 @@ Commit
 Stage and commit the changes.  Write a descriptive commit summary, but try to
 keep it less than 50 characters.  Review your commit.
 
-.. code-block:: shell
+.. code-block:: bash
 
     $ git add salt/modules/alternatives.py
     $ git commit -m 'modules.alternatives: __virtual__ return err msg'
@@ -143,7 +146,7 @@ Push
 Push your branch to your GitHub account.  You will likely need to enter your
 GitHub username and password.
 
-.. code-block:: shell
+.. code-block:: bash
 
     $ git push origin virt_ret
     Username for 'https://github.com': <my_account>
@@ -156,7 +159,7 @@ GitHub username and password.
     you have done this, you may need add the keys to your git repository
     configuration
 
-    .. code-block:: shell
+    .. code-block:: bash
 
         $ git config ssh.key ~/.ssh/<key_name>
 

doc/topics/grains/index.rst

@@ -125,7 +125,7 @@ For this example to work, you would need to have defined the grain
 but too much of the code is similar. To go one step further, Jinja templating
 can be used to simplify the :term:`top file`.
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% set the_node_type = salt['grains.get']('node_type', '') %}
 
@@ -151,9 +151,9 @@ Writing Grains
 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 Python :ref:`dict
+functions in a grains module must return a :ref:`Python dictionary
-<python2:typesmapping>`, where the dictionary keys are the names of grains, and
+<typesmapping>`, where the dictionary keys are the names of grains, and each
-each key's value is that value for that grain.
+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/index.rst

@@ -119,9 +119,9 @@ can use the `Freenode webchat client`_ right from your browser.
 
 `Logs of the IRC channel activity`_ are being collected courtesy of Moritz Lenz.
 
-.. _Freenode:: http://freenode.net/irc_servers.shtml
+.. _Freenode: http://freenode.net/irc_servers.shtml
-.. _Freenode webchat client:: http://webchat.freenode.net/?channels=salt&uio=Mj10cnVlJjk9dHJ1ZSYxMD10cnVl83
+.. _`Freenode webchat client`: http://webchat.freenode.net/?channels=salt&uio=Mj10cnVlJjk9dHJ1ZSYxMD10cnVl83
-.. _Logs of the IRC channel activity:: http://irclog.perlgeek.de/salt/
+.. _`Logs of the IRC channel activity`: http://irclog.perlgeek.de/salt/
 
 If you wish to discuss the development of Salt itself join us in
 ``#salt-devel``.

doc/topics/installation/freebsd.rst

@@ -15,7 +15,7 @@ FreeBSD repo
 The FreeBSD pkgng repository is preconfigured on systems 10.x and above. No
 configuration is needed to pull from these repositories.
 
-.. code-block:: shell
+.. code-block:: bash
 
     pkg install py27-salt
 
@@ -32,7 +32,7 @@ following file to your system:
 
 **/usr/local/etc/pkg/repos/saltstack.conf:**
 
-.. code-block:: json
+.. code-block:: text
 
     saltstack: {
       url: "https://repo.saltstack.com/freebsd/${ABI}/",
@@ -41,7 +41,7 @@ following file to your system:
 
 You should now be able to install Salt from this new repository:
 
-.. code-block:: shell
+.. code-block:: bash
 
     pkg install py27-salt
 
@@ -56,7 +56,7 @@ Post-installation tasks
 
 Copy the sample configuration file:
 
-.. code-block:: shell
+.. code-block:: bash
 
    cp /usr/local/etc/salt/master.sample /usr/local/etc/salt/master
 
@@ -64,7 +64,7 @@ Copy the sample configuration file:
 
 Activate the Salt Master in ``/etc/rc.conf``:
 
-.. code-block:: shell
+.. code-block:: bash
 
    sysrc salt_master_enable="YES"
 
@@ -72,7 +72,7 @@ Activate the Salt Master in ``/etc/rc.conf``:
 
 Start the Salt Master as follows:
 
-.. code-block:: shell
+.. code-block:: bash
 
    service salt_master start
 
@@ -80,7 +80,7 @@ Start the Salt Master as follows:
 
 Copy the sample configuration file:
 
-.. code-block:: shell
+.. code-block:: bash
 
    cp /usr/local/etc/salt/minion.sample /usr/local/etc/salt/minion
 
@@ -88,7 +88,7 @@ Copy the sample configuration file:
 
 Activate the Salt Minion in ``/etc/rc.conf``:
 
-.. code-block:: shell
+.. code-block:: bash
 
    sysrc salt_minion_enable="YES"
 
@@ -96,7 +96,7 @@ Activate the Salt Minion in ``/etc/rc.conf``:
 
 Start the Salt Minion as follows:
 
-.. code-block:: shell
+.. code-block:: bash
 
    service salt_minion start
 

doc/topics/installation/index.rst

@@ -142,7 +142,7 @@ Optional Dependencies
   settings)
 * gcc - dynamic `Cython`_ module compiling
 
-.. _`Python 2.6`: http://python.org/download/
+.. _`Python 2.7`: http://python.org/download/
 .. _`ZeroMQ`: http://zeromq.org/
 .. _`pyzmq`: https://github.com/zeromq/pyzmq
 .. _`msgpack-python`:  https://pypi.python.org/pypi/msgpack-python/

doc/topics/jinja/index.rst

@@ -4,14 +4,13 @@
 Understanding Jinja
 ===================
 
-`Jinja <http://jinja.pocoo.org/docs/>`_ is the default templating language
+`Jinja`_ is the default templating language in SLS files.
-in SLS files.
+
+.. _Jinja: http://jinja.pocoo.org/docs/templates/
 
 Jinja in States
 ===============
 
-.. _Jinja: http://jinja.pocoo.org/docs/templates/
-
 Jinja is evaluated before YAML, which means it is evaluated before the States
 are run.
 
@@ -160,10 +159,9 @@ Saltstack extends `builtin filters`_ with these custom filters:
 ``strftime``
 ------------
 
-Converts any time related object into a time based string. It requires a
+Converts any time related object into a time based string. It requires valid
-valid :ref:`strftime directives <python2:strftime-strptime-behavior>`. An
+strftime directives. An exhaustive list can be found :ref:`here
-:ref:`exhaustive list <python2:strftime-strptime-behavior>` can be found in
+<strftime-strptime-behavior>` in the Python documentation.
-the official Python documentation.
 
 .. code-block:: jinja
 
@@ -1701,7 +1699,7 @@ Logs
 Yes, in Salt, one is able to debug a complex Jinja template using the logs.
 For example, making the call:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {%- do salt.log.error('testing jinja logging') -%}
 

doc/topics/jobs/job_cache.rst

@@ -21,7 +21,7 @@ management.
 
 The default job cache is a temporary cache and jobs will be stored for 24
 hours. If the default cache needs to store jobs for a different period the
-time can be easily adjusted by changing the `keep_jobs` parameter in the
+time can be easily adjusted by changing the ``keep_jobs`` parameter in the
 Salt Master configuration file. The value passed in is measured via hours:
 
 
@@ -47,7 +47,7 @@ checking for and preventing JID collisions.
 The default location for the job cache is in the ``/var/cache/salt/master/jobs/``
 directory.
 
-Setting the :conf_master:`job_cache`` to ``False`` in addition to setting
+Setting the :conf_master:`job_cache` to ``False`` in addition to setting
 the :conf_master:`keep_jobs` option to a smaller value, such as ``1``, in the Salt
 Master configuration file will reduce the size of the Default Job Cache, and thus
 the burden on the Salt Master.

doc/topics/netapi/index.rst

@@ -38,8 +38,8 @@ simply by creating a data structure. (And this is exactly how much of Salt's
 own internals work!)
 
 .. autoclass:: salt.netapi.NetapiClient
-    :members: local, local_async, local_subset, ssh, ssh_async, 
+    :members: local, local_async, local_subset, ssh, runner, runner_async,
-        runner, runner_async, wheel, wheel_async
+        wheel, wheel_async
 
 .. toctree::
 

doc/topics/orchestrate/orchestrate_runner.rst

@@ -198,7 +198,7 @@ To get a more dynamic state, use jinja variables together with
 Using the same example but passing on pillar data, the state would be like
 this.
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     # /srv/salt/orch/deploy.sls
     {% set servers = salt['pillar.get']('servers', 'test') %}

doc/topics/pillar/index.rst

@@ -114,7 +114,7 @@ targeting to them via a top file will have the key of ``company`` with a value
 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>`:
+files, and more via the shared pillar dictionary:
 
 .. code-block:: jinja
 

doc/topics/proxyminion/index.rst

@@ -54,7 +54,7 @@ connection with the remote device only when required.
 New in 2016.11.0
 ----------------
 
-Proxy minions now support configuration files with names ending in '*.conf'
+Proxy minions now support configuration files with names ending in '\*.conf'
 and placed in /etc/salt/proxy.d.
 
 Proxy minions can now be configured in /etc/salt/proxy or /etc/salt/proxy.d
@@ -383,8 +383,9 @@ Pre 2015.8 the proxymodule also must have an ``id()`` function.  2015.8 and foll
 this function because the proxy's id is required on the command line.
 
 Here is an example proxymodule used to interface to a *very* simple REST
-server.  Code for the server is in the `salt-contrib GitHub repository
+server. Code for the server is in the `salt-contrib GitHub repository`_.
-<https://github.com/saltstack/salt-contrib/tree/master/proxyminion_rest_example>`_
+
+.. _`salt-contrib GitHub repository`: https://github.com/saltstack/salt-contrib/tree/master/proxyminion_rest_example
 
 This proxymodule enables "service" enumeration, starting, stopping, restarting,
 and status; "package" installation, and a ping.
@@ -733,7 +734,7 @@ This sections specifically talks about the SSH proxy module and
 explains the working of the example proxy module ``ssh_sample``.
 
 Here is a simple example proxymodule used to interface to a device over SSH.
-Code for the SSH shell is in the `salt-contrib GitHub repository <https://github.com/saltstack/salt-contrib/proxyminion_ssh_example>`_
+Code for the SSH shell is in the `salt-contrib GitHub repository`_.
 
 This proxymodule enables "package" installation.
 

doc/topics/releases/0.6.0.rst

@@ -47,8 +47,6 @@ You can find the source code for Salt on my GitHub page, I have also set up a
 few wiki pages explaining how to use and set up Salt. If you are using Arch
 Linux there is a package available in the Arch Linux AUR.
 
-Salt 0.6.0 Source: :download:`salt-0.6.0.tar.gz`
-
 GitHub page: |saltrepo|
 
 Wiki: https://github.com/saltstack/salt/wiki

doc/topics/releases/0.7.0.rst

@@ -50,12 +50,8 @@ to Matthias Teege for tracking down some configuration bugs!
 
 Salt can be downloaded from the following locations;
 
-Source Tarball:
-
-:download:`salt-0.7.0.tar.gz`
-
 Arch Linux Package:
 
 https://aur.archlinux.org/packages/salt-git/
 
-Please enjoy the latest Salt release!
+Please enjoy the latest Salt release!

doc/topics/releases/0.8.0.rst

@@ -5,8 +5,6 @@ Salt 0.8.0 release notes
 Salt 0.8.0 is ready for general consumption!
 The source tarball is available on GitHub for download:
 
-:download:`salt-0.8.0.tar.gz`
-
 A lot of work has gone into salt since the last release just 2 weeks ago, and
 salt has improved a great deal. A swath of new features are here along with
 performance and threading improvements!

doc/topics/releases/0.8.7.rst

@@ -13,7 +13,6 @@ but the back end to support expansion is in place.
 
 I also recently gave a presentation to the Utah Python users group in Salt Lake
 City, the slides from this presentation are available here:
-:download:`Salt.pdf`
 
 The video from this presentation will be available shortly.
 
@@ -74,7 +73,5 @@ making debugging of minion modules MUCH easier.
 Salt is nearing the goal of 1.0, where the core feature set and capability is
 complete!
 
-Salt 0.8.7 can be downloaded from GitHub here:
-:download:`salt-0.8.7.tar.gz`
 
--Thomas S Hatch
+-Thomas S Hatch

doc/topics/releases/0.8.8.rst

@@ -3,8 +3,7 @@ Salt 0.8.8 release notes
 ========================
 
 Salt 0.8.8 is here! This release adds a great deal of code and some serious new
-features. The latest release can be downloaded here:
+features.
-:download:`salt-0.8.8.tar.gz`
 
 Improved Documentation has been set up for salt using sphinx thanks to the
 efforts of Seth House. This new documentation system will act as the back end
@@ -73,6 +72,5 @@ maintaining supreme usability and simplicity.
 If you would like a more complete overview of Salt please watch the Salt
 presentation:
 Slides:
-:download:`Salt.pdf`
 
--Thomas S Hatch
+-Thomas S Hatch

doc/topics/releases/0.8.9.rst

@@ -17,11 +17,7 @@ date has been filled in.
 Download!
 ---------
 
-The Salt source can be downloaded from the salt GitHub site:
+The Salt source can be downloaded from PyPI:
-
-:download:`salt-0.8.9.tar.gz`
-
-Or from PyPI:
 
 https://pypi.python.org/packages/source/s/salt/salt-0.8.9.tar.gz
 

doc/topics/releases/0.9.0.rst

@@ -14,11 +14,7 @@ improvements to the ZeroMQ systems.
 Download!
 ---------
 
-The Salt source can be downloaded from the salt GitHub site:
+The Salt source can be downloaded from PyPI:
-
-:download:`salt-0.9.0.tar.gz`
-
-Or from PyPI:
 
 https://pypi.python.org/packages/source/s/salt/salt-0.9.0.tar.gz
 
@@ -124,4 +120,4 @@ Extensive utilities for managing processes
 publish
 ~~~~~~~
 
-Used by the peer interface to allow minions to make publications
+Used by the peer interface to allow minions to make publications

doc/topics/releases/0.9.2.rst

@@ -17,11 +17,7 @@ helping us clean up the states interface and make it ready for the world!
 Download!
 ---------
 
-The Salt source can be downloaded from the salt GitHub site:
+The Salt source can be downloaded from PyPI:
-
-:download:`salt-0.9.2.tar.gz`
-
-Or from PyPI:
 
 https://pypi.python.org/packages/source/s/salt/salt-0.9.2.tar.gz
 
@@ -77,4 +73,4 @@ Cython Loading Disabled by Default
 Cython loading requires a development tool chain to be installed on the minion,
 requiring this by default can cause problems for most Salt deployments. If
 Cython auto loading is desired it will need to be turned on in the minion
-config.
+config.

doc/topics/releases/0.9.3.rst

@@ -16,11 +16,7 @@ system has been greatly refined and many new features are available.
 Download!
 ---------
 
-The Salt source can be downloaded from the salt GitHub site:
+The Salt source can be downloaded from PyPI:
-
-:download:`salt-0.9.3.tar.gz`
-
-Or from PyPI:
 
 https://pypi.python.org/packages/source/s/salt/salt-0.9.3.tar.gz