valitydev/salt
14
0
Fork 0
mirror of https://github.com/valitydev/salt.git synced 2024-11-07 08:58:59 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch '2017.7' into wheel_error_error

Browse Source
This commit is contained in:
Mike Place 2018-08-17 16:22:33 +02:00 committed by GitHub
commit ca5df0498e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
924 changed files with 132389 additions and 74459 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
.ci/docs Normal file
View File

@ -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"
}
}
}

73
.ci/kitchen-centos7-py2 Normal file
View File

@ -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}"
}
}
}

73
.ci/kitchen-centos7-py3 Normal file
View File

@ -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}"
}
}
}

73
.ci/kitchen-ubuntu1604-py2 Normal file
View File

@ -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}"
}
}
}

73
.ci/kitchen-ubuntu1604-py3 Normal file
View File

@ -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}"
}
}
}

72
.ci/lint Normal file
View File

@ -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"
}
}
}

1
.github/CODEOWNERS vendored
View File

@ -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

13
.kitchen.yml
View File

@ -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:

7
Gemfile
View File

@ -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

2
doc/.scripts/compile-translation-catalogs
View File

@ -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

2
doc/.scripts/download-translation-catalog
View File

@ -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

2
doc/.scripts/setup-transifex-config
View File

@ -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

2
doc/.scripts/update-transifex-source-translations
View File

@ -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

2
doc/_ext/saltautodoc.py
View File

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

8
doc/_themes/saltstack2/layout.html vendored
View File

@ -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>

BIN
doc/_themes/saltstack2/static/images/DOCBANNER.jpg vendored
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 240 KiB

After

Width:  |  Height:  |  Size: 497 KiB

1
doc/_themes/saltstack2/static/images/SaltStack_white.svg vendored Normal file
View File

@ -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>
Side by Side

After

Width:  |  Height:  |  Size: 3.1 KiB

17
doc/conf.py
View File

@ -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.exceptions',
#'requests',
#'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),
'python3': ('http://docs.python.org/3', None)
'python': ('https://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
previous_release = '2017.7.5' # latest release from previous branch
latest_release = '2018.3.2' # latest release
previous_release = '2017.7.7' # latest release from previous branch
previous_release_dir = '2017.7' # path on web server for previous branch
next_release = '' # next release
next_release_dir = '' # path on web server for next release branch
@ -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 '),
'pull': ('https://github.com/saltstack/salt/pull/%s', 'PR '),
'issue': ('https://github.com/saltstack/salt/issues/%s', 'issue #'),
'pull': ('https://github.com/saltstack/salt/pull/%s', 'PR #'),
'formula_url': ('https://github.com/saltstack-formulas/%s', ''),
}

6
doc/contents.rst
View File

@ -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

23
doc/faq.rst
View File

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

BIN
doc/favicon.ico Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.1 KiB

8
doc/man/salt-api.1
View File

@ -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
\fBsalt(7)\fP
\fBsalt\-master(1)\fP
\fIsalt\-api(7)\fP
\fIsalt(7)\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.

8
doc/man/salt-call.1
View File

@ -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
\fBsalt\-master(1)\fP
\fBsalt\-minion(1)\fP
\fIsalt(1)\fP
\fIsalt\-master(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.

10
doc/man/salt-cloud.1
View File

@ -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
\fBsalt(7)\fP
\fBsalt\-master(1)\fP
\fBsalt\-minion(1)\fP
\fIsalt\-cloud(7)\fP
\fIsalt(7)\fP
\fIsalt\-master(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.

8
doc/man/salt-cp.1
View File

@ -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
\fBsalt\-master(1)\fP
\fBsalt\-minion(1)\fP
\fIsalt(1)\fP
\fIsalt\-master(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.

8
doc/man/salt-key.1
View File

@ -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
\fBsalt\-master(1)\fP
\fBsalt\-minion(1)\fP
\fIsalt(7)\fP
\fIsalt\-master(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.

8
doc/man/salt-master.1
View File

@ -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
\fBsalt(7)\fP
\fBsalt\-minion(1)\fP
\fIsalt(1)\fP
\fIsalt(7)\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.

8
doc/man/salt-minion.1
View File

@ -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
\fBsalt(7)\fP
\fBsalt\-master(1)\fP
\fIsalt(1)\fP
\fIsalt(7)\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.

10
doc/man/salt-proxy.1
View File

@ -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
\fBsalt(7)\fP
\fBsalt\-master(1)\fP
\fBsalt\-minion(1)\fP
\fIsalt(1)\fP
\fIsalt(7)\fP
\fIsalt\-master(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.

8
doc/man/salt-run.1
View File

@ -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
\fBsalt\-master(1)\fP
\fBsalt\-minion(1)\fP
\fIsalt(1)\fP
\fIsalt\-master(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.

8
doc/man/salt-ssh.1
View File

@ -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
\fBsalt\-master(1)\fP
\fBsalt\-minion(1)\fP
\fIsalt(7)\fP
\fIsalt\-master(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.

8
doc/man/salt-syndic.1
View File

@ -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
\fBsalt\-master(1)\fP
\fBsalt\-minion(1)\fP
\fIsalt(1)\fP
\fIsalt\-master(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.

24
doc/man/salt-unity.1
View File

@ -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
\fBsalt\-call(1)\fP
\fBsalt\-cloud(1)\fP
\fBsalt\-cp(1)\fP
\fBsalt\-key(1)\fP
\fBsalt\-main(1)\fP
\fBsalt\-master(1)\fP
\fBsalt\-minion(1)\fP
\fBsalt\-run(1)\fP
\fBsalt\-ssh(1)\fP
\fBsalt\-syndic(1)\fP
\fIsalt\-api(1)\fP
\fIsalt\-call(1)\fP
\fIsalt\-cloud(1)\fP
\fIsalt\-cp(1)\fP
\fIsalt\-key(1)\fP
\fIsalt\-main(1)\fP
\fIsalt\-master(1)\fP
\fIsalt\-minion(1)\fP
\fIsalt\-run(1)\fP
\fIsalt\-ssh(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.

18
doc/man/salt.1
View File

@ -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
\fBsalt\-master(1)\fP
\fBsalt\-minion(1)\fP
\fIsalt(7)\fP
\fIsalt\-master(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.

117368
doc/man/salt.7
View File

File diff suppressed because it is too large Load Diff

8
doc/man/spm.1
View File

@ -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
\fBsalt\-master(1)\fP
\fBsalt\-minion(1)\fP
\fIsalt(1)\fP
\fIsalt\-master(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.

2
doc/ref/beacons/all/salt.beacons.sensehat.rst
View File

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

6
doc/ref/cli/index.rst
View File

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

8
doc/ref/cli/salt.rst
View File

@ -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

1
doc/ref/clients/index.rst
View File

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

36
doc/ref/configuration/logging/index.rst
View File

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

95
doc/ref/configuration/master.rst
View File

@ -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
<transports>`.
what you are doing!
.. 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
This setting has a significant impact on performance and should not be changed unless you know
what you are doing! Transports are explained in :ref:`Salt Transports
<transports>`. The following example shows how to start a TCP transport alongside a ZMQ transport.
(experimental) Starts multiple transports and overrides options for each
transport with the provided dictionary This setting has a significant impact on
performance and should not be changed unless you know what you are doing! The
following example shows how to start a TCP transport alongside a ZMQ transport.
.. code-block:: yaml
@ -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

67
doc/ref/configuration/minion.rst
View File

@ -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
<transports>`.
what you are doing!
.. 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``

4
doc/ref/engines/all/salt.engines.napalm_syslog.rst
View File

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

4
doc/ref/grains/all/salt.grains.metadata.rst
View File

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

1
doc/ref/index.rst
View File

@ -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

30
doc/ref/internals/unicode.rst
View File

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

4
doc/ref/modules/all/index.rst
View File

@ -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

5
doc/ref/modules/all/salt.modules.cytest.rst
View File

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

2
doc/ref/modules/all/salt.modules.napalm_network.rst
View File

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

2
doc/ref/modules/all/salt.modules.pkg.rst
View File

@ -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)``

4
doc/ref/modules/all/salt.modules.service.rst
View File

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

6
doc/ref/modules/all/salt.modules.shadow.rst
View File

@ -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:

11
doc/ref/modules/index.rst
View File

@ -137,7 +137,7 @@ call functions available in other execution modules.
The variable ``__salt__`` is packed into the modules after they are loaded into
the Salt minion.
The ``__salt__`` variable is a :ref:`Python dictionary <python2:typesmapping>`
The ``__salt__`` variable is a :ref:`Python dictionary <typesmapping>`
containing all of the Salt functions. Dictionary keys are strings representing
the names of the modules and the values are the functions themselves.
@ -157,6 +157,7 @@ Calling Execution Modules on the Salt Master
============================================
.. versionadded:: 2016.11.0
Execution modules can now also be called via the :command:`salt-run` command
using the :ref:`salt runner <salt_salt_runner>`.
@ -175,8 +176,8 @@ Grains Data
-----------
The values detected by the Salt Grains on the minion are available in a
:ref:`dict <python2:typesmapping>` named ``__grains__`` and can be accessed
from within callable objects in the Python modules.
:ref:`Python dictionary <typesmapping>` named ``__grains__`` and can be
accessed from within callable objects in the Python modules.
To see the contents of the grains dictionary for a given system in your
deployment run the :func:`grains.items` function:
@ -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.

4
doc/ref/proxy/all/salt.proxy.napalm.rst
View File

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

2
doc/ref/renderers/index.rst
View File

@ -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

8
doc/ref/returners/index.rst
View File

@ -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',
port=6379,
db='0')
host='redis-serv.example.com',
port=6379,
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::

2
doc/ref/states/all/salt.states.rbac_solaris.rst
View File

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

2
doc/ref/states/compiler_ordering.rst
View File

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

2
doc/ref/states/parallel.rst
View File

@ -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:

10
doc/ref/states/requisites.rst
View File

@ -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

4
doc/ref/states/top.rst
View File

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

126
doc/ref/states/writing.rst
View File

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

2
doc/topics/beacons/index.rst
View File

@ -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",

21
doc/topics/best_practices.rst
View File

@ -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

2
doc/topics/cloud/deploy.rst
View File

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

23
doc/topics/cloud/dimensiondata.rst
View File

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

2
doc/topics/cloud/misc.rst
View File

@ -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

20
doc/topics/cloud/proxmox.rst
View File

@ -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
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 ...
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/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 ...

2
doc/topics/cloud/releases/0.8.5.rst
View File

@ -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
===================

2
doc/topics/cloud/virtualbox.rst
View File

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

29
doc/topics/cloud/vmware.rst
View File

@ -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.
.. note::
this will default to 1.
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

4
doc/topics/cloud/windows.rst
View File

@ -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

2
doc/topics/configuration/index.rst
View File

@ -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

20
doc/topics/development/contributing.rst
View File

@ -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
about running Salt's ``.pylintrc`` file. SaltStack recommends running the ``.pylintrc``
file on any files you are changing with your code contribution before submitting a
pull request to Salt's repository. Please see the :ref:`Linting<pylint-instructions>`
documentation for more information.
Within the :ref:`Salt Coding Style <coding-style>` documentation, there is a
section about running Salt's ``.testing.pylintrc`` file. SaltStack recommends
running the ``.testing.pylintrc`` file on any files you are changing with your
code contribution before submitting a pull request to Salt's repository. Please
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:

25
doc/topics/development/conventions/formulas.rst
View File

@ -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:

22
doc/topics/development/conventions/style.rst
View File

@ -22,21 +22,31 @@ improve Salt)!!
Linting
=======
Most Salt style conventions are codified in Salt's ``.pylintrc`` file. Salt's
pylint file has two dependencies: pylint_ and saltpylint_. You can install
these dependencies with ``pip``:
Most Salt style conventions are codified in Salt's ``.testing.pylintrc`` file.
Salt's pylint file has two dependencies: pylint_ and saltpylint_. You can
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
as an argument to the pylint_ program as follows:
The ``.testing.pylintrc`` file is found in the root of the Salt project and can
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

30
doc/topics/development/extend/index.rst
View File

@ -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:

2
doc/topics/development/index.rst
View File

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

416
doc/topics/development/labels.rst
View File

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

21
doc/topics/development/tutorial.rst
View File

@ -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>

8
doc/topics/grains/index.rst
View File

@ -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
<python2:typesmapping>`, where the dictionary keys are the names of grains, and
each key's value is that value for that grain.
functions in a grains module must return a :ref:`Python dictionary
<typesmapping>`, where the dictionary keys are the names of grains, and each
key's value is that value for that grain.
Custom grains modules should be placed in a subdirectory named ``_grains``
located under the :conf_master:`file_roots` specified by the master config

6
doc/topics/index.rst
View File

@ -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 webchat client:: http://webchat.freenode.net/?channels=salt&uio=Mj10cnVlJjk9dHJ1ZSYxMD10cnVl83
.. _Logs of the IRC channel activity:: http://irclog.perlgeek.de/salt/
.. _Freenode: http://freenode.net/irc_servers.shtml
.. _`Freenode webchat client`: http://webchat.freenode.net/?channels=salt&uio=Mj10cnVlJjk9dHJ1ZSYxMD10cnVl83
.. _`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``.

18
doc/topics/installation/freebsd.rst
View File

@ -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

2
doc/topics/installation/index.rst
View File

@ -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/

16
doc/topics/jinja/index.rst
View File

@ -4,14 +4,13 @@
Understanding Jinja
===================
`Jinja <http://jinja.pocoo.org/docs/>`_ is the default templating language
in SLS files.
`Jinja`_ is the default templating language 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
valid :ref:`strftime directives <python2:strftime-strptime-behavior>`. An
:ref:`exhaustive list <python2:strftime-strptime-behavior>` can be found in
the official Python documentation.
Converts any time related object into a time based string. It requires valid
strftime directives. An exhaustive list can be found :ref:`here
<strftime-strptime-behavior>` in the Python documentation.
.. 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') -%}

4
doc/topics/jobs/job_cache.rst
View File

@ -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.

4
doc/topics/netapi/index.rst
View File

@ -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,
runner, runner_async, wheel, wheel_async
:members: local, local_async, local_subset, ssh, runner, runner_async,
wheel, wheel_async
.. toctree::

2
doc/topics/orchestrate/orchestrate_runner.rst
View File

@ -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') %}

2
doc/topics/pillar/index.rst
View File

@ -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

9
doc/topics/proxyminion/index.rst
View File

@ -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
<https://github.com/saltstack/salt-contrib/tree/master/proxyminion_rest_example>`_
server. Code for the server is in the `salt-contrib GitHub repository`_.
.. _`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.

2
doc/topics/releases/0.6.0.rst
View File

@ -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

6
doc/topics/releases/0.7.0.rst
View File

@ -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!

2
doc/topics/releases/0.8.0.rst
View File

@ -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!

5
doc/topics/releases/0.8.7.rst
View File

@ -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

6
doc/topics/releases/0.8.8.rst
View File

@ -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:
:download:`salt-0.8.8.tar.gz`
features.
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

6
doc/topics/releases/0.8.9.rst
View File

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

8
doc/topics/releases/0.9.0.rst
View File

@ -14,11 +14,7 @@ improvements to the ZeroMQ systems.
Download!
---------
The Salt source can be downloaded from the salt GitHub site:
:download:`salt-0.9.0.tar.gz`
Or from PyPI:
The Salt source can be downloaded 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

8
doc/topics/releases/0.9.2.rst
View File

@ -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:
:download:`salt-0.9.2.tar.gz`
Or from PyPI:
The Salt source can be downloaded 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.

6
doc/topics/releases/0.9.3.rst
View File

@ -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:
:download:`salt-0.9.3.tar.gz`
Or from PyPI:
The Salt source can be downloaded from PyPI:
https://pypi.python.org/packages/source/s/salt/salt-0.9.3.tar.gz

Some files were not shown because too many files have changed in this diff Show More