mirror of
https://github.com/valitydev/salt.git
synced 2024-11-07 08:58:59 +00:00
Merge branch '2017.7' into 45014
This commit is contained in:
Frode Gundersen
GitHub
commit
757fde70c6
50
.ci/docs
Normal file
50
.ci/docs
Normal 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"
|
||||
}
|
||||
}
|
||||
}
|
||||
71
.ci/kitchen-centos7-py2
Normal file
71
.ci/kitchen-centos7-py2
Normal file
@ -0,0 +1,71 @@
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
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}"
|
||||
}
|
||||
}
|
||||
}
|
||||
71
.ci/kitchen-centos7-py3
Normal file
71
.ci/kitchen-centos7-py3
Normal file
@ -0,0 +1,71 @@
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
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}"
|
||||
}
|
||||
}
|
||||
}
|
||||
71
.ci/kitchen-ubuntu1604-py2
Normal file
71
.ci/kitchen-ubuntu1604-py2
Normal file
@ -0,0 +1,71 @@
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
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}"
|
||||
}
|
||||
}
|
||||
}
|
||||
71
.ci/kitchen-ubuntu1604-py3
Normal file
71
.ci/kitchen-ubuntu1604-py3
Normal file
@ -0,0 +1,71 @@
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
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}"
|
||||
}
|
||||
}
|
||||
}
|
||||
70
.ci/lint
Normal file
70
.ci/lint
Normal file
@ -0,0 +1,70 @@
|
||||
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 -)"; tox -e pylint-salt | tee pylint-report.xml'
|
||||
archiveArtifacts artifacts: 'pylint-report.xml'
|
||||
}
|
||||
}
|
||||
stage('test linting') {
|
||||
steps {
|
||||
sh 'eval "$(pyenv init -)"; tox -e pylint-tests | tee pylint-report-tests.xml'
|
||||
archiveArtifacts artifacts: 'pylint-report-tests.xml'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
post {
|
||||
always {
|
||||
step([$class: 'WarningsPublisher',
|
||||
parserConfigurations: [[
|
||||
parserName: 'PyLint',
|
||||
pattern: 'pylint-report*.xml'
|
||||
]],
|
||||
failedTotalAll: '1',
|
||||
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"
|
||||
}
|
||||
}
|
||||
}
|
||||
41
.github/CODEOWNERS
vendored
41
.github/CODEOWNERS
vendored
@ -9,52 +9,67 @@
|
||||
# See https://help.github.com/articles/about-codeowners/
|
||||
# for more info about the CODEOWNERS file
|
||||
|
||||
# This file uses an fnmatch-style matching pattern.
|
||||
|
||||
# Team Boto
|
||||
salt/**/*boto* @saltstack/team-boto
|
||||
|
||||
# Team Core
|
||||
salt/auth/ @saltstack/team-core
|
||||
salt/cache/ @saltstack/team-core
|
||||
salt/cli/ @saltstack/team-core
|
||||
salt/auth/* @saltstack/team-core
|
||||
salt/cache/* @saltstack/team-core
|
||||
salt/cli/* @saltstack/team-core
|
||||
salt/client/* @saltstack/team-core
|
||||
salt/config/* @saltstack/team-core
|
||||
salt/daemons/ @saltstack/team-core
|
||||
salt/pillar/ @saltstack/team-core
|
||||
salt/daemons/* @saltstack/team-core
|
||||
salt/pillar/* @saltstack/team-core
|
||||
salt/loader.py @saltstack/team-core
|
||||
salt/payload.py @saltstack/team-core
|
||||
salt/**/master* @saltstack/team-core
|
||||
salt/**/minion* @saltstack/team-core
|
||||
|
||||
# Team Cloud
|
||||
salt/cloud/ @saltstack/team-cloud
|
||||
salt/utils/openstack/ @saltstack/team-cloud
|
||||
salt/cloud/* @saltstack/team-cloud
|
||||
salt/utils/openstack/* @saltstack/team-cloud
|
||||
salt/utils/aws.py @saltstack/team-cloud
|
||||
salt/**/*cloud* @saltstack/team-cloud
|
||||
|
||||
# Team NetAPI
|
||||
salt/cli/api.py @saltstack/team-netapi
|
||||
salt/client/netapi.py @saltstack/team-netapi
|
||||
salt/netapi/ @saltstack/team-netapi
|
||||
salt/netapi/* @saltstack/team-netapi
|
||||
|
||||
# Team Network
|
||||
salt/proxy/ @saltstack/team-proxy
|
||||
salt/proxy/* @saltstack/team-proxy
|
||||
|
||||
# Team SPM
|
||||
salt/cli/spm.py @saltstack/team-spm
|
||||
salt/spm/ @saltstack/team-spm
|
||||
salt/spm/* @saltstack/team-spm
|
||||
|
||||
# Team SSH
|
||||
salt/cli/ssh.py @saltstack/team-ssh
|
||||
salt/client/ssh/ @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
|
||||
|
||||
# Team State
|
||||
salt/state.py @saltstack/team-state
|
||||
|
||||
# Team SUSE
|
||||
salt/**/*btrfs* @saltstack/team-suse
|
||||
salt/**/*kubernetes* @saltstack/team-suse
|
||||
salt/**/*pkg* @saltstack/team-suse
|
||||
salt/**/*snapper* @saltstack/team-suse
|
||||
salt/**/*xfs* @saltstack/team-suse
|
||||
salt/**/*zypper* @saltstack/team-suse
|
||||
|
||||
# Team Transport
|
||||
salt/transport/ @saltstack/team-transport
|
||||
salt/transport/* @saltstack/team-transport
|
||||
salt/utils/zeromq.py @saltstack/team-transport
|
||||
|
||||
# Team Windows
|
||||
salt/**/*win* @saltstack/team-windows
|
||||
salt/*/*win* @saltstack/team-windows
|
||||
salt/modules/reg.py @saltstack/team-windows
|
||||
salt/states/reg.py @saltstack/team-windows
|
||||
tests/*/*win* @saltstack/team-windows
|
||||
tests/*/test_reg.py @saltstack/team-windows
|
||||
|
||||
10
.gitignore
vendored
10
.gitignore
vendored
@ -11,6 +11,8 @@ MANIFEST
|
||||
*.wpr
|
||||
*.wpu
|
||||
*.DS_Store
|
||||
.pytest_cache
|
||||
Pipfile.lock
|
||||
|
||||
# virtualenv
|
||||
# - ignores directories of a virtualenv when you create it right on
|
||||
@ -92,7 +94,9 @@ tests/integration/cloud/providers/pki/minions
|
||||
# Ignore tox virtualenvs
|
||||
/.tox/
|
||||
|
||||
# Ignore kitchen stuff
|
||||
.kitchen
|
||||
.bundle
|
||||
# Kitchen tests files
|
||||
.kitchen.local.yml
|
||||
.kitchen/
|
||||
.bundle/
|
||||
Gemfile.lock
|
||||
/artifacts/
|
||||
|
||||
178
.kitchen.yml
178
.kitchen.yml
@ -1,8 +1,9 @@
|
||||
---
|
||||
<% vagrant = system('which vagrant 2>/dev/null >/dev/null') %>
|
||||
<% version = '2017.7.1' %>
|
||||
<% vagrant = system('gem list -i kitchen-vagrant 2>/dev/null >/dev/null') %>
|
||||
<% 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' %>
|
||||
|
||||
<% if File.exists?(driverfile) %>
|
||||
<%= ERB.new(File.read(driverfile)).result %>
|
||||
@ -10,8 +11,9 @@
|
||||
driver:
|
||||
name: docker
|
||||
use_sudo: false
|
||||
hostname: salt
|
||||
privileged: true
|
||||
username: root
|
||||
username: kitchen
|
||||
volume:
|
||||
- /var/run/docker.sock:/docker.sock
|
||||
cap_add:
|
||||
@ -20,38 +22,55 @@ driver:
|
||||
provision_command:
|
||||
- echo 'L /run/docker.sock - - - - /docker.sock' > /etc/tmpfiles.d/docker.conf
|
||||
transport:
|
||||
name: sftp
|
||||
name: rsync
|
||||
<% end %>
|
||||
|
||||
sudo: false
|
||||
provisioner:
|
||||
name: salt_solo
|
||||
salt_install: bootstrap
|
||||
salt_version: latest
|
||||
salt_bootstrap_url: https://bootstrap.saltstack.com
|
||||
salt_bootstrap_options: -X stable <%= version %>
|
||||
salt_bootstrap_options: -X -p rsync stable <%= version %>
|
||||
log_level: info
|
||||
sudo: true
|
||||
require_chef: false
|
||||
retry_on_exit_code:
|
||||
- 139
|
||||
max_retries: 2
|
||||
remote_states:
|
||||
name: git://github.com/saltstack/salt-jenkins.git
|
||||
branch: 2017.7
|
||||
repo: git
|
||||
testingdir: /testing
|
||||
salt_copy_filter:
|
||||
- __pycache__
|
||||
- '*.pyc'
|
||||
- .bundle
|
||||
- .git
|
||||
- .gitignore
|
||||
- .tox
|
||||
- .kitchen
|
||||
- .kitchen.yml
|
||||
- Gemfile
|
||||
- artifacts
|
||||
- Gemfile.lock
|
||||
- README.rst
|
||||
- .travis.yml
|
||||
state_top:
|
||||
base:
|
||||
"os:Windows":
|
||||
- match: grain
|
||||
- prep_windows
|
||||
"*":
|
||||
- git.salt
|
||||
- kitchen
|
||||
- <%= ENV['KITCHEN_STATE'] || 'git.salt' %>
|
||||
pillars:
|
||||
top.sls:
|
||||
base:
|
||||
"*":
|
||||
- jenkins
|
||||
"os:Windows":
|
||||
- match: grain
|
||||
- windows
|
||||
jenkins.sls:
|
||||
testing_dir: "{{salt.config.get('root_dir')|replace('\\', '\\\\')}}/testing"
|
||||
clone_repo: false
|
||||
salttesting_namespec: salttesting==2017.6.1
|
||||
windows.sls:
|
||||
virtualenv_path: 'c:\Python27\Scripts\pip.exe'
|
||||
<% if File.exists?(platformsfile) %>
|
||||
<%= ERB.new(File.read(platformsfile)).result %>
|
||||
<% else %>
|
||||
@ -61,7 +80,7 @@ platforms:
|
||||
image: fedora:latest
|
||||
run_command: /usr/lib/systemd/systemd
|
||||
provisioner:
|
||||
salt_bootstrap_options: -X git v<%= version %> >/dev/null
|
||||
salt_bootstrap_options: -X -p rsync git v<%= version %> >/dev/null
|
||||
- name: centos-7
|
||||
driver_config:
|
||||
run_command: /usr/lib/systemd/systemd
|
||||
@ -71,13 +90,10 @@ platforms:
|
||||
provision_command:
|
||||
- yum install -y upstart
|
||||
provisioner:
|
||||
salt_bootstrap_options: -P -y -x python2.7 -X git v<%= version %> >/dev/null
|
||||
- name: ubuntu-rolling
|
||||
salt_bootstrap_options: -P -p rsync -y -x python2.7 -X git v<%= version %> >/dev/null
|
||||
- name: ubuntu-18.04
|
||||
driver_config:
|
||||
image: ubuntu:rolling
|
||||
run_command: /lib/systemd/systemd
|
||||
provisioner:
|
||||
salt_bootstrap_url: https://raw.githubusercontent.com/saltstack/salt-bootstrap/develop/bootstrap-salt.sh
|
||||
- name: ubuntu-16.04
|
||||
driver_config:
|
||||
run_command: /lib/systemd/systemd
|
||||
@ -105,7 +121,7 @@ platforms:
|
||||
- systemctl enable sshd
|
||||
- echo 'L /run/docker.sock - - - - /docker.sock' > /etc/tmpfiles.d/docker.conf
|
||||
provisioner:
|
||||
salt_bootstrap_options: -X git v<%= version %> >/dev/null
|
||||
salt_bootstrap_options: -X -p rsync git v<%= version %> >/dev/null
|
||||
- name: opensuse
|
||||
driver_config:
|
||||
run_command: /usr/lib/systemd/systemd
|
||||
@ -113,80 +129,102 @@ platforms:
|
||||
- systemctl enable sshd.service
|
||||
- echo 'L /run/docker.sock - - - - /docker.sock' > /etc/tmpfiles.d/docker.conf
|
||||
provisioner:
|
||||
salt_bootstrap_options: -X git v<%= version %> >/dev/null
|
||||
salt_bootstrap_options: -X -p rsync git v<%= version %> >/dev/null
|
||||
<% if vagrant != false %>
|
||||
- name: windows-2012r2
|
||||
driver:
|
||||
box: mwrock/Windows2012R2
|
||||
communicator: winrm
|
||||
name: vagrant
|
||||
gui: true
|
||||
username: administrator
|
||||
transport:
|
||||
name: winrm
|
||||
username: Administrator
|
||||
password: Pass@word1
|
||||
provisioner:
|
||||
init_environment: |
|
||||
Clear-Host
|
||||
$AddedLocation ="c:\salt"
|
||||
$Reg = "Registry::HKLM\System\CurrentControlSet\Control\Session Manager\Environment"
|
||||
$OldPath = (Get-ItemProperty -Path "$Reg" -Name PATH).Path
|
||||
$NewPath= $OldPath + ’;’ + $AddedLocation
|
||||
Set-ItemProperty -Path "$Reg" -Name PATH –Value $NewPath
|
||||
salt_bootstrap_url: https://raw.githubusercontent.com/saltstack/salt-bootstrap/develop/bootstrap-salt.ps1
|
||||
salt_bootstrap_options: ''
|
||||
- name: windows-2016
|
||||
driver:
|
||||
box: mwrock/Windows2016
|
||||
communicator: winrm
|
||||
name: vagrant
|
||||
username: Vagrant
|
||||
password: vagrant
|
||||
gui: true
|
||||
provisioner:
|
||||
init_environment: |
|
||||
Clear-Host
|
||||
$AddedLocation ="c:\salt;c:\salt\bin\Scripts"
|
||||
$Reg = "Registry::HKLM\System\CurrentControlSet\Control\Session Manager\Environment"
|
||||
$OldPath = (Get-ItemProperty -Path "$Reg" -Name PATH).Path
|
||||
$NewPath= $OldPath + ’;’ + $AddedLocation
|
||||
Set-ItemProperty -Path "$Reg" -Name PATH –Value $NewPath
|
||||
$OldPath = (Get-ItemProperty -Path $Reg -Name PATH).Path
|
||||
$NewPath= $OldPath + ";" + $AddedLocation
|
||||
Set-ItemProperty -Path $Reg -Value $NewPath -Name PATH
|
||||
reg add "hklm\system\currentcontrolset\control\session manager\memory management" /v pagingfiles /t reg_multi_sz /d "d:\pagefile.sys 4096 8192" /f
|
||||
winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="5000"}'
|
||||
salt_bootstrap_url: https://raw.githubusercontent.com/saltstack/salt-bootstrap/develop/bootstrap-salt.ps1
|
||||
salt_bootstrap_options: ''
|
||||
verifier:
|
||||
windows: true
|
||||
types:
|
||||
- unit
|
||||
coverage_xml: false
|
||||
save:
|
||||
$env:TEMP/salt-runtests.log: artifacts/logs/salt-runtests.log
|
||||
/salt/var/log/salt/minion: artifacts/logs/minion
|
||||
- name: windows-2016
|
||||
driver:
|
||||
box: mwrock/Windows2016
|
||||
name: vagrant
|
||||
gui: true
|
||||
transport:
|
||||
name: winrm
|
||||
username: Administrator
|
||||
password: vagrant
|
||||
provisioner:
|
||||
init_environment: |
|
||||
Clear-Host
|
||||
$AddedLocation ="c:\salt;c:\salt\bin\Scripts"
|
||||
$Reg = "Registry::HKLM\System\CurrentControlSet\Control\Session Manager\Environment"
|
||||
$OldPath = (Get-ItemProperty -Path $Reg -Name PATH).Path
|
||||
$NewPath= $OldPath + ";" + $AddedLocation
|
||||
Set-ItemProperty -Path $Reg -Value $NewPath -Name PATH
|
||||
reg add "hklm\system\currentcontrolset\control\session manager\memory management" /v pagingfiles /t reg_multi_sz /d "d:\pagefile.sys 4096 8192" /f
|
||||
winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="5000"}'
|
||||
salt_bootstrap_url: https://raw.githubusercontent.com/saltstack/salt-bootstrap/develop/bootstrap-salt.ps1
|
||||
salt_bootstrap_options: ''
|
||||
verifier:
|
||||
windows: true
|
||||
types:
|
||||
- unit
|
||||
coverage_xml: false
|
||||
xml: /tmp/xml-unittests-output/
|
||||
save:
|
||||
/tmp/xml-unittests-output/: artifacts/
|
||||
$env:TEMP/salt-runtests.log: artifacts/logs/salt-runtests.log
|
||||
/salt/var/log/salt/minion: artifacts/logs/minion
|
||||
<% end %>
|
||||
<% end %>
|
||||
suites:
|
||||
- name: py2
|
||||
provisioner:
|
||||
pillars:
|
||||
top.sls:
|
||||
base:
|
||||
"*":
|
||||
- jenkins
|
||||
jenkins.sls:
|
||||
testing_dir: /tmp/kitchen/testing
|
||||
clone_repo: false
|
||||
salttesting_namespec: salttesting==2017.6.1
|
||||
verifier:
|
||||
python_bin: python2.7
|
||||
- name: py3
|
||||
excludes:
|
||||
- centos-6
|
||||
- ubuntu-14.04
|
||||
verifier:
|
||||
python_bin: python3
|
||||
provisioner:
|
||||
pillars:
|
||||
top.sls:
|
||||
base:
|
||||
"*":
|
||||
- jenkins
|
||||
jenkins.sls:
|
||||
testing_dir: /tmp/kitchen/testing
|
||||
clone_repo: false
|
||||
py3: true
|
||||
salttesting_namespec: salttesting==2017.6.1
|
||||
verifier:
|
||||
name: shell
|
||||
remote_exec: true
|
||||
sudo: false
|
||||
live_stream: {}
|
||||
<% if ENV['TESTOPTS'].nil? %>
|
||||
command: '$(kitchen) /tmp/kitchen/testing/tests/runtests.py --run-destructive --sysinfo --transport=zeromq --output-columns=80 --ssh --coverage-xml=/tmp/coverage.xml --xml=/tmp/xml-unittests-output'
|
||||
windows.sls:
|
||||
virtualenv_path: 'c:\Python35\Scripts\pip.exe'
|
||||
|
||||
<% if File.exists?(verifierfile) %>
|
||||
<%= ERB.new(File.read(verifierfile)).result %>
|
||||
<% else %>
|
||||
command: '$(kitchen) /tmp/kitchen/testing/tests/runtests.py --run-destructive --output-columns 80 <%= ENV["TESTOPTS"] %>'
|
||||
verifier:
|
||||
name: runtests
|
||||
sudo: true
|
||||
run_destructive: true
|
||||
transport: zeromq
|
||||
types:
|
||||
- ssh
|
||||
xml: /tmp/xml-unittests-output/
|
||||
coverage_xml: /tmp/coverage.xml
|
||||
save:
|
||||
/tmp/xml-unittests-output: artifacts/
|
||||
/tmp/coverage.xml: artifacts/coverage/coverage.xml
|
||||
/tmp/kitchen/var/log/salt/minion: artifacts/logs/minion
|
||||
/tmp/salt-runtests.log: artifacts/logs/salt-runtests.log
|
||||
<% end %>
|
||||
|
||||
@ -11,7 +11,7 @@ profile=no
|
||||
|
||||
# Add files or directories to the blacklist. They should be base names, not
|
||||
# paths.
|
||||
ignore=CVS
|
||||
ignore=CVS,ext
|
||||
|
||||
# Pickle collected data for later comparisons.
|
||||
persistent=yes
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
|
||||
# Add files or directories to the blacklist. They should be base names, not
|
||||
# paths.
|
||||
ignore=CVS
|
||||
ignore=CVS,ext
|
||||
|
||||
# Pickle collected data for later comparisons.
|
||||
persistent=no
|
||||
@ -29,6 +29,25 @@ load-plugins=saltpylint.pep8,
|
||||
# Don't bump this values on PyLint 1.4.0 - Know bug that ignores the passed --rcfile
|
||||
jobs=1
|
||||
|
||||
# List of blacklisted functions and suggested replacements
|
||||
#
|
||||
# NOTE: This pylint check will infer the full name of the function by walking
|
||||
# back up from the function name to the parent, to the parent's parent, etc.,
|
||||
# and this means that functions which come from platform-specific modules need
|
||||
# to be referenced using name of the module from which the function was
|
||||
# imported. This happens a lot in the os and os.path modules. Functions from
|
||||
# os.path should be defined using posixpath.funcname and ntpath.funcname, while
|
||||
# functions from os should be defined using posix.funcname and nt.funcname.
|
||||
#
|
||||
# When defining a blacklisted function, the format is:
|
||||
#
|
||||
# <func_name>=<suggested_replacement>
|
||||
#
|
||||
# The replacement text will be included in the alert message.
|
||||
#
|
||||
blacklisted-functions=posix.umask=salt.utils.files.set_umask or get_umask,
|
||||
nt.umask=salt.utils.files.set_umask or get_umask
|
||||
|
||||
# Allow loading of arbitrary C extensions. Extensions are imported into the
|
||||
# active Python interpreter and may run arbitrary code.
|
||||
unsafe-load-any-extension=no
|
||||
|
||||
12
Gemfile
12
Gemfile
@ -2,8 +2,8 @@
|
||||
|
||||
source 'https://rubygems.org'
|
||||
|
||||
gem 'test-kitchen'
|
||||
gem 'kitchen-salt', :git => 'https://github.com/saltstack/kitchen-salt.git'
|
||||
gem 'test-kitchen', '~>1.21'
|
||||
gem 'kitchen-salt', '~>0.2'
|
||||
gem 'kitchen-sync'
|
||||
gem 'git'
|
||||
|
||||
@ -12,7 +12,7 @@ group :docker do
|
||||
end
|
||||
|
||||
group :opennebula do
|
||||
gem 'kitchen-opennebula', :git => 'https://github.com/gtmanfred/kitchen-opennebula.git'
|
||||
gem 'kitchen-opennebula', '>=0.2.3'
|
||||
gem 'xmlrpc'
|
||||
end
|
||||
|
||||
@ -20,5 +20,9 @@ group :windows do
|
||||
gem 'vagrant-wrapper'
|
||||
gem 'kitchen-vagrant'
|
||||
gem 'winrm', '~>2.0'
|
||||
gem 'winrm-fs', '~>1.0'
|
||||
gem 'winrm-fs', :git => 'https://github.com/WinRb/winrm-fs.git'
|
||||
end
|
||||
|
||||
group :ec2 do
|
||||
gem 'kitchen-ec2'
|
||||
end
|
||||
|
||||
40
Pipfile
Normal file
40
Pipfile
Normal file
@ -0,0 +1,40 @@
|
||||
[[source]]
|
||||
url = "https://pypi.org/simple"
|
||||
verify_ssl = true
|
||||
name = "pypi"
|
||||
|
||||
[packages]
|
||||
Jinja2 = "*"
|
||||
msgpack-python = ">0.3,!=0.5.5"
|
||||
PyYAML = "*"
|
||||
MarkupSafe = "*"
|
||||
requests = ">=1.0.0"
|
||||
tornado = ">=4.2.1,<5.0"
|
||||
pycrypto = ">=2.6.1"
|
||||
pyzmq = ">=2.2.0"
|
||||
|
||||
[dev-packages]
|
||||
mock = ">=2.0.0"
|
||||
apache-libcloud = ">=0.14.0"
|
||||
boto = ">=2.32.1"
|
||||
boto3 = ">=1.2.1"
|
||||
moto = ">=0.3.6"
|
||||
SaltPyLint = ">=v2017.3.6"
|
||||
pytest = ">=3.5.0"
|
||||
|
||||
[packages.futures]
|
||||
# Required by Tornado to handle threads stuff.
|
||||
version = ">=2.0"
|
||||
markers = "python_version < '3.0'"
|
||||
|
||||
[dev-packages.pytest-salt]
|
||||
git = "git://github.com/saltstack/pytest-salt.git"
|
||||
ref = "master"
|
||||
|
||||
[dev-packages.httpretty]
|
||||
# httpretty Needs to be here for now even though it's a dependency of boto.
|
||||
# A pip install on a fresh system will decide to target httpretty 0.8.10 to
|
||||
# satisfy other requirements, and httpretty 0.8.10 has bugs in setup.py that
|
||||
# prevent it from being successfully installed (at least on Python 3.4).
|
||||
version = "*"
|
||||
markers = "python_version >= '3.4'"
|
||||
@ -67,8 +67,8 @@ Engage SaltStack
|
||||
|
||||
`SaltConf`_, **User Groups and Meetups** - SaltStack has a vibrant and `global
|
||||
community`_ of customers, users, developers and enthusiasts. Connect with other
|
||||
Salted folks in your area of the world, or join `SaltConf16`_, the SaltStack
|
||||
annual user conference, April 19-21 in Salt Lake City. Please let us know if
|
||||
Salted folks in your area of the world, or join `SaltConf18`_, the SaltStack
|
||||
annual user conference, September 10-14 in Salt Lake City. Please let us know if
|
||||
you would like to start a user group or if we should add your existing
|
||||
SaltStack user group to this list by emailing: info@saltstack.com
|
||||
|
||||
@ -91,7 +91,7 @@ services`_ offerings.
|
||||
|
||||
.. _SaltConf: http://www.youtube.com/user/saltstack
|
||||
.. _global community: http://www.meetup.com/pro/saltstack/
|
||||
.. _SaltConf16: http://saltconf.com/
|
||||
.. _SaltConf18: http://saltconf.com/
|
||||
.. _SaltStack education offerings: http://saltstack.com/training/
|
||||
.. _SaltStack Certified Engineer (SSCE): http://saltstack.com/certification/
|
||||
.. _SaltStack professional services: http://saltstack.com/services/
|
||||
|
||||
@ -235,13 +235,13 @@
|
||||
# cause sub minion process to restart.
|
||||
#auth_safemode: False
|
||||
|
||||
# Ping Master to ensure connection is alive (seconds).
|
||||
# Ping Master to ensure connection is alive (minutes).
|
||||
#ping_interval: 0
|
||||
|
||||
# To auto recover minions if master changes IP address (DDNS)
|
||||
# auth_tries: 10
|
||||
# auth_safemode: False
|
||||
# ping_interval: 90
|
||||
# ping_interval: 2
|
||||
#
|
||||
# Minions won't know master is missing until a ping fails. After the ping fail,
|
||||
# the minion will attempt authentication and likely fails out and cause a restart.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# -*- coding: utf-8 -*-
|
||||
'''
|
||||
:codeauthor: :email:`Pedro Algarvio (pedro@algarvio.me)`
|
||||
:codeauthor: Pedro Algarvio (pedro@algarvio.me)
|
||||
|
||||
|
||||
saltautodoc.py
|
||||
|
||||
@ -38,7 +38,10 @@ from __future__ import division
|
||||
import re
|
||||
from docutils import nodes
|
||||
from docutils.parsers.rst import directives
|
||||
from sphinx.util.compat import Directive
|
||||
try:
|
||||
from sphinx.util.compat import Directive
|
||||
except ImportError:
|
||||
from docutils.parsers.rst import Directive
|
||||
|
||||
CONTROL_HEIGHT = 30
|
||||
|
||||
|
||||
6
doc/_themes/saltstack2/layout.html
vendored
6
doc/_themes/saltstack2/layout.html
vendored
@ -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
BIN
doc/_themes/saltstack2/static/images/DOCBANNER.jpg
vendored
Binary file not shown.
|
Before Width: | Height: | Size: 438 KiB After Width: | Height: | Size: 589 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 739 KiB After Width: | Height: | Size: 109 KiB |
42
doc/conf.py
42
doc/conf.py
@ -46,6 +46,8 @@ class Mock(object):
|
||||
data = self.__mapping.get(name)
|
||||
elif name in ('__file__', '__path__'):
|
||||
data = '/dev/null'
|
||||
elif name == '__qualname__':
|
||||
raise AttributeError("'Mock' object has no attribute '__qualname__'")
|
||||
else:
|
||||
data = Mock(mapping=self.__mapping)
|
||||
return data
|
||||
@ -104,6 +106,7 @@ MOCK_MODULES = [
|
||||
|
||||
'tornado',
|
||||
'tornado.concurrent',
|
||||
'tornado.escape',
|
||||
'tornado.gen',
|
||||
'tornado.httpclient',
|
||||
'tornado.httpserver',
|
||||
@ -135,8 +138,8 @@ MOCK_MODULES = [
|
||||
'pymongo',
|
||||
'rabbitmq_server',
|
||||
'redis',
|
||||
'requests',
|
||||
'requests.exceptions',
|
||||
#'requests',
|
||||
#'requests.exceptions',
|
||||
'rpm',
|
||||
'rpmUtils',
|
||||
'rpmUtils.arch',
|
||||
@ -158,6 +161,7 @@ MOCK_MODULES = [
|
||||
'jnpr.junos.utils.sw',
|
||||
'dns',
|
||||
'dns.resolver',
|
||||
'keyring',
|
||||
'netaddr',
|
||||
'netaddr.IPAddress',
|
||||
'netaddr.core',
|
||||
@ -199,6 +203,8 @@ def mock_decorator_with_params(*oargs, **okwargs):
|
||||
|
||||
# Define a fake version attribute for the following libs.
|
||||
sys.modules['libcloud'].__version__ = '0.0.0'
|
||||
sys.modules['msgpack'].version = (1, 0, 0)
|
||||
sys.modules['psutil'].version_info = (3, 0, 0)
|
||||
sys.modules['pymongo'].version = '0.0.0'
|
||||
sys.modules['ntsecuritycon'].STANDARD_RIGHTS_REQUIRED = 0
|
||||
sys.modules['ntsecuritycon'].SYNCHRONIZE = 0
|
||||
@ -232,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 -------------------------------------------------
|
||||
|
||||
@ -245,9 +250,9 @@ on_saltstack = 'SALT_ON_SALTSTACK' in os.environ
|
||||
project = 'Salt'
|
||||
|
||||
version = salt.version.__version__
|
||||
latest_release = '2017.7.2' # latest release
|
||||
previous_release = '2016.11.8' # latest release from previous branch
|
||||
previous_release_dir = '2016.11' # path on web server for 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
|
||||
|
||||
@ -258,8 +263,8 @@ if on_saltstack:
|
||||
copyright = time.strftime("%Y")
|
||||
|
||||
# < --- START do not merge these settings to other branches START ---> #
|
||||
build_type = 'latest' # latest, previous, develop, next
|
||||
release = latest_release # version, latest_release, previous_release
|
||||
build_type = 'previous' # latest, previous, develop, next
|
||||
release = previous_release # version, latest_release, previous_release
|
||||
# < --- END do not merge these settings to other branches END ---> #
|
||||
|
||||
# Set google custom search engine
|
||||
@ -318,6 +323,7 @@ rst_prolog = """\
|
||||
.. _`salt-users`: https://groups.google.com/forum/#!forum/salt-users
|
||||
.. _`salt-announce`: https://groups.google.com/forum/#!forum/salt-announce
|
||||
.. _`salt-packagers`: https://groups.google.com/forum/#!forum/salt-packagers
|
||||
.. _`salt-slack`: https://saltstackcommunity.herokuapp.com/
|
||||
.. |windownload| raw:: html
|
||||
|
||||
<p>Python2 x86: <a
|
||||
@ -336,19 +342,23 @@ rst_prolog = """\
|
||||
| <a href="https://repo.saltstack.com/windows/Salt-Minion-{release}-Py3-AMD64-Setup.exe.md5"><strong>md5</strong></a></p>
|
||||
|
||||
|
||||
.. |osxdownload| raw:: html
|
||||
.. |osxdownloadpy2| raw:: html
|
||||
|
||||
<p>x86_64: <a href="https://repo.saltstack.com/osx/salt-{release}-x86_64.pkg"><strong>salt-{release}-x86_64.pkg</strong></a>
|
||||
| <a href="https://repo.saltstack.com/osx/salt-{release}-x86_64.pkg.md5"><strong>md5</strong></a></p>
|
||||
<p>x86_64: <a href="https://repo.saltstack.com/osx/salt-{release}-py2-x86_64.pkg"><strong>salt-{release}-py2-x86_64.pkg</strong></a>
|
||||
| <a href="https://repo.saltstack.com/osx/salt-{release}-py2-x86_64.pkg.md5"><strong>md5</strong></a></p>
|
||||
|
||||
.. |osxdownloadpy3| raw:: html
|
||||
|
||||
<p>x86_64: <a href="https://repo.saltstack.com/osx/salt-{release}-py3-x86_64.pkg"><strong>salt-{release}-py3-x86_64.pkg</strong></a>
|
||||
| <a href="https://repo.saltstack.com/osx/salt-{release}-py3-x86_64.pkg.md5"><strong>md5</strong></a></p>
|
||||
|
||||
""".format(release=release)
|
||||
|
||||
# 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', ''),
|
||||
}
|
||||
|
||||
@ -360,7 +370,7 @@ gettext_compact = False
|
||||
|
||||
|
||||
### HTML options
|
||||
html_theme = 'saltstack2' #change to 'saltstack' to use previous theme
|
||||
html_theme = os.environ.get('HTML_THEME', 'saltstack2') # set 'HTML_THEME=saltstack' to use previous theme
|
||||
html_theme_path = ['_themes']
|
||||
html_title = u''
|
||||
html_short_title = 'Salt'
|
||||
|
||||
@ -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
|
||||
|
||||
60
doc/faq.rst
60
doc/faq.rst
@ -148,22 +148,23 @@ Why aren't my custom modules/states/etc. available on my Minions?
|
||||
-----------------------------------------------------------------
|
||||
|
||||
Custom modules are synced to Minions when
|
||||
:mod:`saltutil.sync_modules <salt.modules.saltutil.sync_modules>`,
|
||||
or :mod:`saltutil.sync_all <salt.modules.saltutil.sync_all>` is run.
|
||||
Custom modules are also synced by :mod:`state.apply` when run without
|
||||
any arguments.
|
||||
:py:func:`saltutil.sync_modules <salt.modules.saltutil.sync_modules>`,
|
||||
or :py:func:`saltutil.sync_all <salt.modules.saltutil.sync_all>` is run.
|
||||
|
||||
Similarly, custom states are synced to Minions when :py:func:`saltutil.sync_states
|
||||
<salt.modules.saltutil.sync_states>`, or :py:func:`saltutil.sync_all
|
||||
<salt.modules.saltutil.sync_all>` is run.
|
||||
|
||||
Similarly, custom states are synced to Minions
|
||||
when :mod:`state.apply <salt.modules.state.apply_>`,
|
||||
:mod:`saltutil.sync_states <salt.modules.saltutil.sync_states>`, or
|
||||
:mod:`saltutil.sync_all <salt.modules.saltutil.sync_all>` is run.
|
||||
They are both also synced when a :ref:`highstate <running-highstate>` is
|
||||
triggered.
|
||||
|
||||
Custom states are also synced by :mod:`state.apply<salt.modules.state.apply_>`
|
||||
when run without any arguments.
|
||||
As of the Fluorine release, as well as 2017.7.7 and 2018.3.2 in their
|
||||
respective release cycles, the ``sync`` argument to :py:func:`state.apply
|
||||
<salt.modules.state.apply_>`/:py:func:`state.sls <salt.modules.state.sls>` can
|
||||
be used to sync custom types when running individual SLS files.
|
||||
|
||||
Other custom types (renderers, outputters, etc.) have similar behavior, see the
|
||||
documentation for the :mod:`saltutil <salt.modules.saltutil>` module for more
|
||||
documentation for the :py:func:`saltutil <salt.modules.saltutil>` module for more
|
||||
information.
|
||||
|
||||
:ref:`This reactor example <minion-start-reactor>` can be used to automatically
|
||||
@ -254,17 +255,19 @@ specifying the pillar variable is the same one used for :py:func:`pillar.get
|
||||
<salt.states.file.managed>` state is only supported in Salt 2015.8.4 and
|
||||
newer.
|
||||
|
||||
.. _faq-restart-salt-minion:
|
||||
|
||||
What is the best way to restart a Salt Minion daemon using Salt after upgrade?
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
Updating the ``salt-minion`` package requires a restart of the ``salt-minion``
|
||||
service. But restarting the service while in the middle of a state run
|
||||
interrupts the process of the Minion running states and sending results back to
|
||||
the Master. A common way to workaround that is to schedule restarting of the
|
||||
Minion service using :ref:`masterless mode <masterless-quickstart>` after all
|
||||
other states have been applied. This allows the minion to keep Minion to Master
|
||||
connection alive for the Minion to report the final results to the Master, while
|
||||
the service is restarting in the background.
|
||||
the Master. A common way to workaround that is to schedule restarting the
|
||||
Minion service in the background by issuing a ``salt-call`` command calling
|
||||
``service.restart`` function. This prevents the Minion being disconnected from
|
||||
the Master immediately. Otherwise you would get
|
||||
``Minion did not return. [Not connected]`` message as the result of a state run.
|
||||
|
||||
Upgrade without automatic restart
|
||||
*********************************
|
||||
@ -325,10 +328,10 @@ The following example works on UNIX-like operating systems:
|
||||
|
||||
.. code-block:: jinja
|
||||
|
||||
{%- if grains['os'] != 'Windows' %
|
||||
{%- if grains['os'] != 'Windows' %}
|
||||
Restart Salt Minion:
|
||||
cmd.run:
|
||||
- name: 'salt-call --local service.restart salt-minion'
|
||||
- name: 'salt-call service.restart salt-minion'
|
||||
- bg: True
|
||||
- onchanges:
|
||||
- pkg: Upgrade Salt Minion
|
||||
@ -348,9 +351,9 @@ as follows:
|
||||
Restart Salt Minion:
|
||||
cmd.run:
|
||||
{%- if grains['kernel'] == 'Windows' %}
|
||||
- name: 'C:\salt\salt-call.bat --local service.restart salt-minion'
|
||||
- name: 'C:\salt\salt-call.bat service.restart salt-minion'
|
||||
{%- else %}
|
||||
- name: 'salt-call --local service.restart salt-minion'
|
||||
- name: 'salt-call service.restart salt-minion'
|
||||
{%- endif %}
|
||||
- bg: True
|
||||
- onchanges:
|
||||
@ -358,7 +361,13 @@ as follows:
|
||||
|
||||
However, it requires more advanced tricks to upgrade from legacy version of
|
||||
Salt (before ``2016.3.0``) on UNIX-like operating systems, where executing
|
||||
commands in the background is not supported:
|
||||
commands in the background is not supported. You also may need to schedule
|
||||
restarting the Minion service using :ref:`masterless mode
|
||||
<masterless-quickstart>` after all other states have been applied for Salt
|
||||
versions earlier than ``2016.11.0``. This allows the Minion to keep the
|
||||
connection to the Master alive for being able to report the final results back
|
||||
to the Master, while the service is restarting in the background. This state
|
||||
should run last or watch for the ``pkg`` state changes:
|
||||
|
||||
.. code-block:: jinja
|
||||
|
||||
@ -382,8 +391,8 @@ Restart the Minion from the command line:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt -G kernel:Windows cmd.run_bg 'C:\salt\salt-call.bat --local service.restart salt-minion'
|
||||
salt -C 'not G@kernel:Windows' cmd.run_bg 'salt-call --local service.restart salt-minion'
|
||||
salt -G kernel:Windows cmd.run_bg 'C:\salt\salt-call.bat service.restart salt-minion'
|
||||
salt -C 'not G@kernel:Windows' cmd.run_bg 'salt-call service.restart salt-minion'
|
||||
|
||||
Salting the Salt Master
|
||||
-----------------------
|
||||
@ -409,6 +418,10 @@ for salt itself:
|
||||
|
||||
https://github.com/saltstack-formulas/salt-formula
|
||||
|
||||
Restarting the ``salt-master`` service using execution module or application of
|
||||
state could be done the same way as for the Salt minion described :ref:`above
|
||||
<faq-restart-salt-minion>`.
|
||||
|
||||
.. _faq-grain-security:
|
||||
|
||||
Is Targeting using Grain Data Secure?
|
||||
@ -443,4 +456,3 @@ the grain and values that you want to change / set.)
|
||||
|
||||
You should also `file an issue <https://github.com/saltstack/salt/issues>`_
|
||||
describing the change so it can be fixed in Salt.
|
||||
|
||||
|
||||
BIN
doc/favicon.ico
Normal file
BIN
doc/favicon.ico
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.1 KiB |
@ -1,6 +1,6 @@
|
||||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "SALT-API" "1" "October 31, 2016" "2016.11.0" "Salt"
|
||||
.TH "SALT-API" "1" "Jun 14, 2018" "2017.7.7" "Salt"
|
||||
.SH NAME
|
||||
salt-api \- salt-api Command
|
||||
.
|
||||
@ -103,12 +103,10 @@ Logfile logging log level. One of \fBall\fP, \fBgarbage\fP, \fBtrace\fP,
|
||||
.UNINDENT
|
||||
.SH SEE ALSO
|
||||
.sp
|
||||
\fIsalt\-api(7)\fP
|
||||
\fIsalt(7)\fP
|
||||
\fIsalt\-master(1)\fP
|
||||
\fBsalt\-api(7)\fP
|
||||
\fBsalt(7)\fP
|
||||
\fBsalt\-master(1)\fP
|
||||
.SH AUTHOR
|
||||
Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
|
||||
.SH COPYRIGHT
|
||||
2016 SaltStack, Inc.
|
||||
.\" Generated by docutils manpage writer.
|
||||
.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "SALT-CALL" "1" "October 31, 2016" "2016.11.0" "Salt"
|
||||
.TH "SALT-CALL" "1" "Jun 14, 2018" "2017.7.7" "Salt"
|
||||
.SH NAME
|
||||
salt-call \- salt-call Documentation
|
||||
.
|
||||
@ -227,6 +227,11 @@ Write the output to the specified file.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-out\-file\-append, \-\-output\-file\-append
|
||||
Append the output to the specified file.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-no\-color
|
||||
Disable all colored output
|
||||
.UNINDENT
|
||||
@ -245,14 +250,25 @@ changes and success and \fByellow\fP denotes a expected future change in configu
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-state\-output=STATE_OUTPUT, \-\-state_output=STATE_OUTPUT
|
||||
Override the configured state_output value for minion
|
||||
output. One of \(aqfull\(aq, \(aqterse\(aq, \(aqmixed\(aq, \(aqchanges\(aq or
|
||||
\(aqfilter\(aq. Default: \(aqnone\(aq.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-state\-verbose=STATE_VERBOSE, \-\-state_verbose=STATE_VERBOSE
|
||||
Override the configured state_verbose value for minion
|
||||
output. Set to True or False. Default: none.
|
||||
.UNINDENT
|
||||
.SH SEE ALSO
|
||||
.sp
|
||||
\fIsalt(1)\fP
|
||||
\fIsalt\-master(1)\fP
|
||||
\fIsalt\-minion(1)\fP
|
||||
\fBsalt(1)\fP
|
||||
\fBsalt\-master(1)\fP
|
||||
\fBsalt\-minion(1)\fP
|
||||
.SH AUTHOR
|
||||
Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
|
||||
.SH COPYRIGHT
|
||||
2016 SaltStack, Inc.
|
||||
.\" Generated by docutils manpage writer.
|
||||
.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "SALT-CLOUD" "1" "October 31, 2016" "2016.11.0" "Salt"
|
||||
.TH "SALT-CLOUD" "1" "Jun 14, 2018" "2017.7.7" "Salt"
|
||||
.SH NAME
|
||||
salt-cloud \- Salt Cloud Command
|
||||
.
|
||||
@ -276,6 +276,11 @@ Write the output to the specified file.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-out\-file\-append, \-\-output\-file\-append
|
||||
Append the output to the specified file.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-no\-color
|
||||
Disable all colored output
|
||||
.UNINDENT
|
||||
@ -294,6 +299,19 @@ changes and success and \fByellow\fP denotes a expected future change in configu
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-state\-output=STATE_OUTPUT, \-\-state_output=STATE_OUTPUT
|
||||
Override the configured state_output value for minion
|
||||
output. One of \(aqfull\(aq, \(aqterse\(aq, \(aqmixed\(aq, \(aqchanges\(aq or
|
||||
\(aqfilter\(aq. Default: \(aqnone\(aq.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-state\-verbose=STATE_VERBOSE, \-\-state_verbose=STATE_VERBOSE
|
||||
Override the configured state_verbose value for minion
|
||||
output. Set to True or False. Default: none.
|
||||
.UNINDENT
|
||||
.SH EXAMPLES
|
||||
.sp
|
||||
To create 4 VMs named web1, web2, db1, and db2 from specified profiles:
|
||||
@ -369,13 +387,11 @@ salt\-cloud \-m /path/to/cloud.map \-Q
|
||||
.UNINDENT
|
||||
.SH SEE ALSO
|
||||
.sp
|
||||
\fIsalt\-cloud(7)\fP
|
||||
\fIsalt(7)\fP
|
||||
\fIsalt\-master(1)\fP
|
||||
\fIsalt\-minion(1)\fP
|
||||
\fBsalt\-cloud(7)\fP
|
||||
\fBsalt(7)\fP
|
||||
\fBsalt\-master(1)\fP
|
||||
\fBsalt\-minion(1)\fP
|
||||
.SH AUTHOR
|
||||
Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
|
||||
.SH COPYRIGHT
|
||||
2016 SaltStack, Inc.
|
||||
.\" Generated by docutils manpage writer.
|
||||
.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "SALT-CP" "1" "October 31, 2016" "2016.11.0" "Salt"
|
||||
.TH "SALT-CP" "1" "Jun 14, 2018" "2017.7.7" "Salt"
|
||||
.SH NAME
|
||||
salt-cp \- salt-cp Documentation
|
||||
.
|
||||
@ -31,34 +31,55 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
|
||||
.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
|
||||
..
|
||||
.sp
|
||||
Copy a file to a set of systems
|
||||
Copy a file or files to one or more minions
|
||||
.SH SYNOPSIS
|
||||
.INDENT 0.0
|
||||
.INDENT 3.5
|
||||
.sp
|
||||
.nf
|
||||
.ft C
|
||||
salt\-cp \(aq*\(aq [ options ] SOURCE DEST
|
||||
salt\-cp \(aq*\(aq [ options ] SOURCE [SOURCE2 SOURCE3 ...] DEST
|
||||
|
||||
salt\-cp \-E \(aq.*\(aq [ options ] SOURCE DEST
|
||||
salt\-cp \-E \(aq.*\(aq [ options ] SOURCE [SOURCE2 SOURCE3 ...] DEST
|
||||
|
||||
salt\-cp \-G \(aqos:Arch.*\(aq [ options ] SOURCE DEST
|
||||
salt\-cp \-G \(aqos:Arch.*\(aq [ options ] SOURCE [SOURCE2 SOURCE3 ...] DEST
|
||||
.ft P
|
||||
.fi
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.SH DESCRIPTION
|
||||
.sp
|
||||
Salt copy copies a local file out to all of the Salt minions matched by the
|
||||
given target.
|
||||
salt\-cp copies files from the master to all of the Salt minions matched by the
|
||||
specified target expression.
|
||||
.sp
|
||||
Salt copy is only intended for use with small files (< 100KB). If you need
|
||||
to copy large files out to minions please use the cp.get_file function.
|
||||
.sp
|
||||
Note: salt\-cp uses salt\(aqs publishing mechanism. This means the privacy of the
|
||||
\fBNOTE:\fP
|
||||
.INDENT 0.0
|
||||
.INDENT 3.5
|
||||
salt\-cp uses Salt\(aqs publishing mechanism. This means the privacy of the
|
||||
contents of the file on the wire is completely dependent upon the transport
|
||||
in use. In addition, if the salt\-master is running with debug logging it is
|
||||
possible that the contents of the file will be logged to disk.
|
||||
in use. In addition, if the master or minion is running with debug logging,
|
||||
the contents of the file will be logged to disk.
|
||||
.sp
|
||||
In addition, this tool is less efficient than the Salt fileserver when
|
||||
copying larger files. It is recommended to instead use
|
||||
\fBcp.get_file\fP to copy larger files to
|
||||
minions. However, this requires the file to be located within one of the
|
||||
fileserver directories.
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.sp
|
||||
Changed in version 2016.3.7,2016.11.6,2017.7.0: Compression support added, disable with \fB\-n\fP\&. Also, if the destination
|
||||
path ends in a path separator (i.e. \fB/\fP, or \fB\e\fP on Windows, the
|
||||
desitination will be assumed to be a directory. Finally, recursion is now
|
||||
supported, allowing for entire directories to be copied.
|
||||
|
||||
.sp
|
||||
Changed in version 2016.11.7,2017.7.2: Reverted back to the old copy mode to preserve backward compatibility. The
|
||||
new functionality added in 2016.6.6 and 2017.7.0 is now available using the
|
||||
\fB\-C\fP or \fB\-\-chunked\fP CLI arguments. Note that compression, recursive
|
||||
copying, and support for copying large files is only available in chunked
|
||||
mode.
|
||||
|
||||
.SH OPTIONS
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
@ -160,15 +181,30 @@ to identify targets. Range expressions look like %cluster.
|
||||
Using the Range option requires that a range server is set up and the
|
||||
location of the range server is referenced in the master configuration
|
||||
file.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-C, \-\-chunked
|
||||
Use new chunked mode to copy files. This mode supports large files, recursive
|
||||
directories copying and compression.
|
||||
.sp
|
||||
New in version 2016.11.7,2017.7.2.
|
||||
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-n, \-\-no\-compression
|
||||
Disable gzip compression in chunked mode.
|
||||
.sp
|
||||
New in version 2016.3.7,2016.11.6,2017.7.0.
|
||||
|
||||
.UNINDENT
|
||||
.SH SEE ALSO
|
||||
.sp
|
||||
\fIsalt(1)\fP
|
||||
\fIsalt\-master(1)\fP
|
||||
\fIsalt\-minion(1)\fP
|
||||
\fBsalt(1)\fP
|
||||
\fBsalt\-master(1)\fP
|
||||
\fBsalt\-minion(1)\fP
|
||||
.SH AUTHOR
|
||||
Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
|
||||
.SH COPYRIGHT
|
||||
2016 SaltStack, Inc.
|
||||
.\" Generated by docutils manpage writer.
|
||||
.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "SALT-KEY" "1" "October 31, 2016" "2016.11.0" "Salt"
|
||||
.TH "SALT-KEY" "1" "Jun 14, 2018" "2017.7.7" "Salt"
|
||||
.SH NAME
|
||||
salt-key \- salt-key Documentation
|
||||
.
|
||||
@ -182,6 +182,11 @@ Write the output to the specified file.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-out\-file\-append, \-\-output\-file\-append
|
||||
Append the output to the specified file.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-no\-color
|
||||
Disable all colored output
|
||||
.UNINDENT
|
||||
@ -200,6 +205,19 @@ changes and success and \fByellow\fP denotes a expected future change in configu
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-state\-output=STATE_OUTPUT, \-\-state_output=STATE_OUTPUT
|
||||
Override the configured state_output value for minion
|
||||
output. One of \(aqfull\(aq, \(aqterse\(aq, \(aqmixed\(aq, \(aqchanges\(aq or
|
||||
\(aqfilter\(aq. Default: \(aqnone\(aq.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-state\-verbose=STATE_VERBOSE, \-\-state_verbose=STATE_VERBOSE
|
||||
Override the configured state_verbose value for minion
|
||||
output. Set to True or False. Default: none.
|
||||
.UNINDENT
|
||||
.SS Actions
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
@ -322,12 +340,10 @@ Auto\-create a signing key\-pair if it does not yet exist
|
||||
.UNINDENT
|
||||
.SH SEE ALSO
|
||||
.sp
|
||||
\fIsalt(7)\fP
|
||||
\fIsalt\-master(1)\fP
|
||||
\fIsalt\-minion(1)\fP
|
||||
\fBsalt(7)\fP
|
||||
\fBsalt\-master(1)\fP
|
||||
\fBsalt\-minion(1)\fP
|
||||
.SH AUTHOR
|
||||
Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
|
||||
.SH COPYRIGHT
|
||||
2016 SaltStack, Inc.
|
||||
.\" Generated by docutils manpage writer.
|
||||
.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "SALT-MASTER" "1" "October 31, 2016" "2016.11.0" "Salt"
|
||||
.TH "SALT-MASTER" "1" "Jun 14, 2018" "2017.7.7" "Salt"
|
||||
.SH NAME
|
||||
salt-master \- salt-master Documentation
|
||||
.
|
||||
@ -108,12 +108,10 @@ Logfile logging log level. One of \fBall\fP, \fBgarbage\fP, \fBtrace\fP,
|
||||
.UNINDENT
|
||||
.SH SEE ALSO
|
||||
.sp
|
||||
\fIsalt(1)\fP
|
||||
\fIsalt(7)\fP
|
||||
\fIsalt\-minion(1)\fP
|
||||
\fBsalt(1)\fP
|
||||
\fBsalt(7)\fP
|
||||
\fBsalt\-minion(1)\fP
|
||||
.SH AUTHOR
|
||||
Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
|
||||
.SH COPYRIGHT
|
||||
2016 SaltStack, Inc.
|
||||
.\" Generated by docutils manpage writer.
|
||||
.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "SALT-MINION" "1" "October 31, 2016" "2016.11.0" "Salt"
|
||||
.TH "SALT-MINION" "1" "Jun 14, 2018" "2017.7.7" "Salt"
|
||||
.SH NAME
|
||||
salt-minion \- salt-minion Documentation
|
||||
.
|
||||
@ -109,12 +109,10 @@ Logfile logging log level. One of \fBall\fP, \fBgarbage\fP, \fBtrace\fP,
|
||||
.UNINDENT
|
||||
.SH SEE ALSO
|
||||
.sp
|
||||
\fIsalt(1)\fP
|
||||
\fIsalt(7)\fP
|
||||
\fIsalt\-master(1)\fP
|
||||
\fBsalt(1)\fP
|
||||
\fBsalt(7)\fP
|
||||
\fBsalt\-master(1)\fP
|
||||
.SH AUTHOR
|
||||
Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
|
||||
.SH COPYRIGHT
|
||||
2016 SaltStack, Inc.
|
||||
.\" Generated by docutils manpage writer.
|
||||
.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "SALT-PROXY" "1" "October 31, 2016" "2016.11.0" "Salt"
|
||||
.TH "SALT-PROXY" "1" "Jun 14, 2018" "2017.7.7" "Salt"
|
||||
.SH NAME
|
||||
salt-proxy \- salt-proxy Documentation
|
||||
.
|
||||
@ -116,13 +116,11 @@ Logfile logging log level. One of \fBall\fP, \fBgarbage\fP, \fBtrace\fP,
|
||||
.UNINDENT
|
||||
.SH SEE ALSO
|
||||
.sp
|
||||
\fIsalt(1)\fP
|
||||
\fIsalt(7)\fP
|
||||
\fIsalt\-master(1)\fP
|
||||
\fIsalt\-minion(1)\fP
|
||||
\fBsalt(1)\fP
|
||||
\fBsalt(7)\fP
|
||||
\fBsalt\-master(1)\fP
|
||||
\fBsalt\-minion(1)\fP
|
||||
.SH AUTHOR
|
||||
Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
|
||||
.SH COPYRIGHT
|
||||
2016 SaltStack, Inc.
|
||||
.\" Generated by docutils manpage writer.
|
||||
.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "SALT-RUN" "1" "October 31, 2016" "2016.11.0" "Salt"
|
||||
.TH "SALT-RUN" "1" "Jun 14, 2018" "2017.7.7" "Salt"
|
||||
.SH NAME
|
||||
salt-run \- salt-run Documentation
|
||||
.
|
||||
@ -114,12 +114,10 @@ Logfile logging log level. One of \fBall\fP, \fBgarbage\fP, \fBtrace\fP,
|
||||
.UNINDENT
|
||||
.SH SEE ALSO
|
||||
.sp
|
||||
\fIsalt(1)\fP
|
||||
\fIsalt\-master(1)\fP
|
||||
\fIsalt\-minion(1)\fP
|
||||
\fBsalt(1)\fP
|
||||
\fBsalt\-master(1)\fP
|
||||
\fBsalt\-minion(1)\fP
|
||||
.SH AUTHOR
|
||||
Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
|
||||
.SH COPYRIGHT
|
||||
2016 SaltStack, Inc.
|
||||
.\" Generated by docutils manpage writer.
|
||||
.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "SALT-SSH" "1" "October 31, 2016" "2016.11.0" "Salt"
|
||||
.TH "SALT-SSH" "1" "Jun 14, 2018" "2017.7.7" "Salt"
|
||||
.SH NAME
|
||||
salt-ssh \- salt-ssh Documentation
|
||||
.
|
||||
@ -49,13 +49,35 @@ Salt SSH allows for salt routines to be executed using only SSH for transport
|
||||
.SH OPTIONS
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-r, \-\-raw, \-\-raw\-shell
|
||||
Execute a raw shell command.
|
||||
.B \-\-version
|
||||
Print the version of Salt that is running.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-priv
|
||||
Specify the SSH private key file to be used for authentication.
|
||||
.B \-\-versions\-report
|
||||
Show program\(aqs dependencies and version number, and then exit
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-h, \-\-help
|
||||
Show the help message and exit
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-c CONFIG_DIR, \-\-config\-dir=CONFIG_dir
|
||||
The location of the Salt configuration directory. This directory contains
|
||||
the configuration files for Salt master and minions. The default location
|
||||
on most systems is \fB/etc/salt\fP\&.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-hard\-crash
|
||||
Raise any original exception rather than exiting gracefully. Default: False.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-r, \-\-raw, \-\-raw\-shell
|
||||
Execute a raw shell command.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
@ -90,9 +112,74 @@ is 25.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-extra\-filerefs=EXTRA_FILEREFS
|
||||
Pass in extra files to include in the state tarball.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-min\-extra\-modules=MIN_EXTRA_MODS
|
||||
One or comma\-separated list of extra Python modulesto be included
|
||||
into Minimal Salt.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-thin\-extra\-modules=THIN_EXTRA_MODS
|
||||
One or comma\-separated list of extra Python modulesto be included
|
||||
into Thin Salt.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-v, \-\-verbose
|
||||
Turn on command verbosity, display jid.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-s, \-\-static
|
||||
Return the data from minions as a group after they all return.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-w, \-\-wipe
|
||||
Remove the deployment of the salt files when done executing.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-W, \-\-rand\-thin\-dir
|
||||
Select a random temp dir to deploy on the remote system. The dir
|
||||
will be cleaned after the execution.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-t, \-\-regen\-thin, \-\-thin
|
||||
Trigger a thin tarball regeneration. This is needed if custom
|
||||
grains/modules/states have been added or updated.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-python2\-bin=PYTHON2_BIN
|
||||
Path to a python2 binary which has salt installed.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-python3\-bin=PYTHON3_BIN
|
||||
Path to a python3 binary which has salt installed.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-jid=JID
|
||||
Pass a JID to be used instead of generating one.
|
||||
.UNINDENT
|
||||
.SS Authentication Options
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-priv=SSH_PRIV
|
||||
Specify the SSH private key file to be used for authentication.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-i, \-\-ignore\-host\-keys
|
||||
Disables StrictHostKeyChecking to relax acceptance of new and unknown
|
||||
host keys.
|
||||
By default ssh host keys are honored and connections will ask for
|
||||
approval. Use this option to disable StrictHostKeyChecking.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
@ -103,11 +190,22 @@ changed and would still error with \-\-ignore\-host\-keys.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-user=SSH_USER
|
||||
Set the default user to attempt to use when authenticating.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-passwd
|
||||
Set the default password to attempt to use when authenticating.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-askpass
|
||||
Interactively ask for the SSH password with no echo \- avoids password
|
||||
in process args and stored in history.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-key\-deploy
|
||||
Set this flag to attempt to deploy the authorized ssh key with all
|
||||
minions. This combined with \-\-passwd can make initial deployment of keys
|
||||
@ -115,35 +213,25 @@ very fast and easy.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-version
|
||||
Print the version of Salt that is running.
|
||||
.B \-\-identities\-only
|
||||
Use the only authentication identity files configured in the ssh_config
|
||||
files. See IdentitiesOnly flag in man ssh_config.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-versions\-report
|
||||
Show program\(aqs dependencies and version number, and then exit
|
||||
.B \-\-sudo
|
||||
Run command via sudo.
|
||||
.UNINDENT
|
||||
.SS Scan Roster Options
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-scan\-ports=SSH_SCAN_PORTS
|
||||
Comma\-separated list of ports to scan in the scan roster.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-h, \-\-help
|
||||
Show the help message and exit
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-c CONFIG_DIR, \-\-config\-dir=CONFIG_dir
|
||||
The location of the Salt configuration directory. This directory contains
|
||||
the configuration files for Salt master and minions. The default location
|
||||
on most systems is \fB/etc/salt\fP\&.
|
||||
.UNINDENT
|
||||
.SS Target Selection
|
||||
.sp
|
||||
The default matching that Salt utilizes is shell\-style globbing around the
|
||||
minion id. See \fI\%https://docs.python.org/2/library/fnmatch.html#module\-fnmatch\fP\&.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-E, \-\-pcre
|
||||
The target expression will be interpreted as a PCRE regular expression
|
||||
rather than a shell glob.
|
||||
.B \-\-scan\-timeout=SSH_SCAN_TIMEOUT
|
||||
Scanning socket timeout for the scan roster.
|
||||
.UNINDENT
|
||||
.SS Logging Options
|
||||
.sp
|
||||
@ -167,6 +255,16 @@ Logfile logging log level. One of \fBall\fP, \fBgarbage\fP, \fBtrace\fP,
|
||||
\fBdebug\fP, \fBinfo\fP, \fBwarning\fP, \fBerror\fP, \fBquiet\fP\&. Default:
|
||||
\fBwarning\fP\&.
|
||||
.UNINDENT
|
||||
.SS Target Selection
|
||||
.sp
|
||||
The default matching that Salt utilizes is shell\-style globbing around the
|
||||
minion id. See \fI\%https://docs.python.org/2/library/fnmatch.html#module\-fnmatch\fP\&.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-E, \-\-pcre
|
||||
The target expression will be interpreted as a PCRE regular expression
|
||||
rather than a shell glob.
|
||||
.UNINDENT
|
||||
.SS Output Options
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
@ -212,6 +310,11 @@ Write the output to the specified file.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-out\-file\-append, \-\-output\-file\-append
|
||||
Append the output to the specified file.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-no\-color
|
||||
Disable all colored output
|
||||
.UNINDENT
|
||||
@ -230,14 +333,25 @@ changes and success and \fByellow\fP denotes a expected future change in configu
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-state\-output=STATE_OUTPUT, \-\-state_output=STATE_OUTPUT
|
||||
Override the configured state_output value for minion
|
||||
output. One of \(aqfull\(aq, \(aqterse\(aq, \(aqmixed\(aq, \(aqchanges\(aq or
|
||||
\(aqfilter\(aq. Default: \(aqnone\(aq.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-state\-verbose=STATE_VERBOSE, \-\-state_verbose=STATE_VERBOSE
|
||||
Override the configured state_verbose value for minion
|
||||
output. Set to True or False. Default: none.
|
||||
.UNINDENT
|
||||
.SH SEE ALSO
|
||||
.sp
|
||||
\fIsalt(7)\fP
|
||||
\fIsalt\-master(1)\fP
|
||||
\fIsalt\-minion(1)\fP
|
||||
\fBsalt(7)\fP
|
||||
\fBsalt\-master(1)\fP
|
||||
\fBsalt\-minion(1)\fP
|
||||
.SH AUTHOR
|
||||
Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
|
||||
.SH COPYRIGHT
|
||||
2016 SaltStack, Inc.
|
||||
.\" Generated by docutils manpage writer.
|
||||
.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "SALT-SYNDIC" "1" "October 31, 2016" "2016.11.0" "Salt"
|
||||
.TH "SALT-SYNDIC" "1" "Jun 14, 2018" "2017.7.7" "Salt"
|
||||
.SH NAME
|
||||
salt-syndic \- salt-syndic Documentation
|
||||
.
|
||||
@ -110,12 +110,10 @@ Logfile logging log level. One of \fBall\fP, \fBgarbage\fP, \fBtrace\fP,
|
||||
.UNINDENT
|
||||
.SH SEE ALSO
|
||||
.sp
|
||||
\fIsalt(1)\fP
|
||||
\fIsalt\-master(1)\fP
|
||||
\fIsalt\-minion(1)\fP
|
||||
\fBsalt(1)\fP
|
||||
\fBsalt\-master(1)\fP
|
||||
\fBsalt\-minion(1)\fP
|
||||
.SH AUTHOR
|
||||
Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
|
||||
.SH COPYRIGHT
|
||||
2016 SaltStack, Inc.
|
||||
.\" Generated by docutils manpage writer.
|
||||
.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "SALT-UNITY" "1" "October 31, 2016" "2016.11.0" "Salt"
|
||||
.TH "SALT-UNITY" "1" "Jun 14, 2018" "2017.7.7" "Salt"
|
||||
.SH NAME
|
||||
salt-unity \- salt-unity Command
|
||||
.
|
||||
@ -50,20 +50,18 @@ invokes that script.
|
||||
.SH OPTIONS
|
||||
.SH SEE ALSO
|
||||
.sp
|
||||
\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
|
||||
\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
|
||||
.SH AUTHOR
|
||||
Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
|
||||
.SH COPYRIGHT
|
||||
2016 SaltStack, Inc.
|
||||
.\" Generated by docutils manpage writer.
|
||||
.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "SALT" "1" "October 31, 2016" "2016.11.0" "Salt"
|
||||
.TH "SALT" "1" "Jun 14, 2018" "2017.7.7" "Salt"
|
||||
.SH NAME
|
||||
salt \- salt
|
||||
.
|
||||
@ -306,6 +306,11 @@ Write the output to the specified file.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-out\-file\-append, \-\-output\-file\-append
|
||||
Append the output to the specified file.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-no\-color
|
||||
Disable all colored output
|
||||
.UNINDENT
|
||||
@ -324,14 +329,25 @@ changes and success and \fByellow\fP denotes a expected future change in configu
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-state\-output=STATE_OUTPUT, \-\-state_output=STATE_OUTPUT
|
||||
Override the configured state_output value for minion
|
||||
output. One of \(aqfull\(aq, \(aqterse\(aq, \(aqmixed\(aq, \(aqchanges\(aq or
|
||||
\(aqfilter\(aq. Default: \(aqnone\(aq.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-state\-verbose=STATE_VERBOSE, \-\-state_verbose=STATE_VERBOSE
|
||||
Override the configured state_verbose value for minion
|
||||
output. Set to True or False. Default: none.
|
||||
.UNINDENT
|
||||
.SH SEE ALSO
|
||||
.sp
|
||||
\fIsalt(7)\fP
|
||||
\fIsalt\-master(1)\fP
|
||||
\fIsalt\-minion(1)\fP
|
||||
\fBsalt(7)\fP
|
||||
\fBsalt\-master(1)\fP
|
||||
\fBsalt\-minion(1)\fP
|
||||
.SH AUTHOR
|
||||
Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
|
||||
.SH COPYRIGHT
|
||||
2016 SaltStack, Inc.
|
||||
.\" Generated by docutils manpage writer.
|
||||
.
|
||||
|
||||
148147
doc/man/salt.7
148147
doc/man/salt.7
File diff suppressed because it is too large
Load Diff
@ -1,6 +1,6 @@
|
||||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "SPM" "1" "October 31, 2016" "2016.11.0" "Salt"
|
||||
.TH "SPM" "1" "Jun 14, 2018" "2017.7.7" "Salt"
|
||||
.SH NAME
|
||||
spm \- Salt Package Manager Command
|
||||
.
|
||||
@ -132,12 +132,10 @@ in that directory which describes them.
|
||||
.UNINDENT
|
||||
.SH SEE ALSO
|
||||
.sp
|
||||
\fIsalt(1)\fP
|
||||
\fIsalt\-master(1)\fP
|
||||
\fIsalt\-minion(1)\fP
|
||||
\fBsalt(1)\fP
|
||||
\fBsalt\-master(1)\fP
|
||||
\fBsalt\-minion(1)\fP
|
||||
.SH AUTHOR
|
||||
Thomas S. Hatch <thatch45@gmail.com> and many others, please see the Authors file
|
||||
.SH COPYRIGHT
|
||||
2016 SaltStack, Inc.
|
||||
.\" Generated by docutils manpage writer.
|
||||
.
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
salt.beacons.sensehat module
|
||||
=======================
|
||||
============================
|
||||
|
||||
.. automodule:: salt.beacons.sensehat
|
||||
:members:
|
||||
|
||||
@ -74,6 +74,12 @@ salt-syndic
|
||||
|
||||
salt-syndic
|
||||
|
||||
salt-unity
|
||||
==========
|
||||
.. toctree::
|
||||
|
||||
salt-unity
|
||||
|
||||
salt-api
|
||||
========
|
||||
.. toctree::
|
||||
|
||||
@ -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
|
||||
|
||||
@ -72,6 +72,7 @@ Each module type has a corresponding loader function.
|
||||
Salt's Client Interfaces
|
||||
========================
|
||||
|
||||
.. _client-interfaces:
|
||||
.. _local-client:
|
||||
|
||||
LocalClient
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
.. _all-salt.clouds:
|
||||
|
||||
===============================
|
||||
Full list of Salt Cloud modules
|
||||
===============================
|
||||
=============
|
||||
cloud modules
|
||||
=============
|
||||
|
||||
.. currentmodule:: salt.cloud.clouds
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -225,15 +227,16 @@ enclosing brackets ``[`` and ``]``:
|
||||
|
||||
Default: ``{}``
|
||||
|
||||
This can be used to control logging levels more specifically. The example sets
|
||||
the main salt library at the 'warning' level, but sets ``salt.modules`` to log
|
||||
at the ``debug`` level:
|
||||
This can be used to control logging levels more specifically, based on log call name. The example sets
|
||||
the main salt library at the 'warning' level, sets ``salt.modules`` to log
|
||||
at the ``debug`` level, and sets a custom module to the ``all`` level:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
log_granular_levels:
|
||||
'salt': 'warning'
|
||||
'salt.modules': 'debug'
|
||||
'salt.loader.saltmaster.ext.module.custom_module': 'all'
|
||||
|
||||
External Logging Handlers
|
||||
-------------------------
|
||||
|
||||
@ -519,7 +519,7 @@ Default: ``0``
|
||||
|
||||
Memcache is an additional cache layer that keeps a limited amount of data
|
||||
fetched from the minion data cache for a limited period of time in memory that
|
||||
makes cache operations faster. It doesn't make much sence for the ``localfs``
|
||||
makes cache operations faster. It doesn't make much sense for the ``localfs``
|
||||
cache driver but helps for more complex drivers like ``consul``.
|
||||
|
||||
This option sets the memcache items expiration time. By default is set to ``0``
|
||||
@ -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``
|
||||
-----------------------
|
||||
@ -956,12 +930,61 @@ The TCP port for ``mworkers`` to connect to on the master.
|
||||
|
||||
tcp_master_workers: 4515
|
||||
|
||||
.. conf_master:: auth_events
|
||||
|
||||
``auth_events``
|
||||
--------------------
|
||||
|
||||
.. versionadded:: 2017.7.3
|
||||
|
||||
Default: ``True``
|
||||
|
||||
Determines whether the master will fire authentication events.
|
||||
:ref:`Authentication events <event-master_auth>` are fired when
|
||||
a minion performs an authentication check with the master.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
auth_events: True
|
||||
|
||||
.. conf_master:: minion_data_cache_events
|
||||
|
||||
``minion_data_cache_events``
|
||||
----------------------------
|
||||
|
||||
.. versionadded:: 2017.7.3
|
||||
|
||||
Default: ``True``
|
||||
|
||||
Determines whether the master will fire minion data cache events. Minion data
|
||||
cache events are fired when a minion requests a minion data cache refresh.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
minion_data_cache_events: True
|
||||
|
||||
.. _salt-ssh-configuration:
|
||||
|
||||
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``
|
||||
@ -1555,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``
|
||||
|
||||
@ -1587,7 +1610,7 @@ the master will drop the request and the minion's key will remain accepted.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
rotate_aes_key: True
|
||||
allow_minion_key_revoke: False
|
||||
|
||||
|
||||
Master Large Scale Tuning Settings
|
||||
@ -3836,7 +3859,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
|
||||
@ -3884,12 +3907,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
|
||||
|
||||
@ -3997,6 +4022,25 @@ Recursively merge lists by aggregating them instead of replacing them.
|
||||
|
||||
pillar_merge_lists: False
|
||||
|
||||
.. conf_master:: pillar_includes_override_sls
|
||||
|
||||
``pillar_includes_override_sls``
|
||||
********************************
|
||||
|
||||
.. versionadded:: 2017.7.6,2018.3.1
|
||||
|
||||
Default: ``False``
|
||||
|
||||
Prior to version 2017.7.3, keys from :ref:`pillar includes <pillar-include>`
|
||||
would be merged on top of the pillar SLS. Since 2017.7.3, the includes are
|
||||
merged together and then the pillar SLS is merged on top of that.
|
||||
|
||||
Set this option to ``True`` to return to the old behavior.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
pillar_includes_override_sls: True
|
||||
|
||||
.. _pillar-cache-opts:
|
||||
|
||||
Pillar Cache Options
|
||||
@ -4118,6 +4162,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
|
||||
@ -4820,11 +4865,10 @@ branch/tag.
|
||||
|
||||
winrepo_branch: winrepo
|
||||
|
||||
ext_pillar:
|
||||
- git:
|
||||
- https://mygitserver/winrepo1.git
|
||||
- https://mygitserver/winrepo2.git:
|
||||
- foo https://mygitserver/winrepo3.git
|
||||
winrepo_remotes:
|
||||
- https://mygitserver/winrepo1.git
|
||||
- https://mygitserver/winrepo2.git:
|
||||
- foo https://mygitserver/winrepo3.git
|
||||
|
||||
.. conf_master:: winrepo_ssl_verify
|
||||
|
||||
@ -4967,7 +5011,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
|
||||
|
||||
@ -303,6 +303,20 @@ option on the Salt master.
|
||||
|
||||
master_port: 4506
|
||||
|
||||
.. conf_minion:: publish_port
|
||||
|
||||
``publish_port``
|
||||
----------------
|
||||
|
||||
Default: ``4505``
|
||||
|
||||
The port of the master publish server, this needs to coincide with the publish_port
|
||||
option on the Salt master.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
publish_port: 4505
|
||||
|
||||
.. conf_minion:: user
|
||||
|
||||
``user``
|
||||
@ -418,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,
|
||||
@ -808,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``
|
||||
--------------
|
||||
@ -869,7 +883,7 @@ restart.
|
||||
|
||||
Default: ``0``
|
||||
|
||||
Instructs the minion to ping its master(s) every n number of seconds. Used
|
||||
Instructs the minion to ping its master(s) every n number of minutes. Used
|
||||
primarily as a mitigation technique against minion disconnects.
|
||||
|
||||
.. code-block:: yaml
|
||||
@ -1076,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
|
||||
|
||||
@ -1149,6 +1162,40 @@ 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
|
||||
|
||||
|
||||
Minion Module Management
|
||||
========================
|
||||
|
||||
@ -1356,7 +1403,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
|
||||
|
||||
@ -2316,6 +2363,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
|
||||
@ -2338,7 +2386,7 @@ Thread Settings
|
||||
.. conf_minion:: multiprocessing
|
||||
|
||||
``multiprocessing``
|
||||
-------
|
||||
-------------------
|
||||
|
||||
Default: ``True``
|
||||
|
||||
@ -2736,6 +2784,27 @@ the metadata will be refreshed.
|
||||
|
||||
.. _winrepo-minion-config-opts:
|
||||
|
||||
Minion Windows Software Repo Settings
|
||||
=====================================
|
||||
|
||||
.. important::
|
||||
To use these config options, the minion can be running in master-minion or
|
||||
masterless mode.
|
||||
|
||||
|
||||
.. conf_minion:: winrepo_source_dir
|
||||
|
||||
``winrepo_source_dir``
|
||||
----------------------
|
||||
|
||||
Default: ``salt://win/repo-ng/``
|
||||
|
||||
The source location for the winrepo sls files.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
winrepo_source_dir: salt://win/repo-ng/
|
||||
|
||||
Standalone Minion Windows Software Repo Settings
|
||||
================================================
|
||||
|
||||
@ -2779,19 +2848,6 @@ out for 2015.8.0 and later minions.
|
||||
|
||||
winrepo_dir_ng: /srv/salt/win/repo-ng
|
||||
|
||||
.. conf_minion:: winrepo_source_dir
|
||||
|
||||
``winrepo_source_dir``
|
||||
----------------------
|
||||
|
||||
Default: ``salt://win/repo-ng/``
|
||||
|
||||
The source location for the winrepo sls files.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
winrepo_source_dir: salt://win/repo-ng/
|
||||
|
||||
.. conf_minion:: winrepo_cachefile
|
||||
.. conf_minion:: win_repo_cachefile
|
||||
|
||||
|
||||
@ -108,7 +108,7 @@ The frequency of keepalive checks, in minutes. It requires the
|
||||
|
||||
Default: ``True``
|
||||
|
||||
Wheter the proxy should maintain the connection with the remote
|
||||
Whether the proxy should maintain the connection with the remote
|
||||
device. Similarly to :conf_proxy:`proxy_keep_alive`, this option
|
||||
is very specific to the design of the proxy module.
|
||||
When :conf_proxy:`proxy_always_alive` is set to ``False``,
|
||||
@ -126,7 +126,7 @@ has to be closed after every command.
|
||||
|
||||
Default: ``False``.
|
||||
|
||||
Wheter the pillar data to be merged into the proxy configuration options.
|
||||
Whether the pillar data to be merged into the proxy configuration options.
|
||||
As multiple proxies can run on the same server, we may need different
|
||||
configuration options for each, while there's one single configuration file.
|
||||
The solution is merging the pillar data of each proxy minion into the opts.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
===========================
|
||||
==========================
|
||||
salt.engines.napalm_syslog
|
||||
===========================
|
||||
==========================
|
||||
|
||||
.. automodule:: salt.engines.napalm_syslog
|
||||
:members:
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
=================
|
||||
====================
|
||||
salt.grains.metadata
|
||||
=================
|
||||
====================
|
||||
|
||||
.. automodule:: salt.grains.metadata
|
||||
:members:
|
||||
|
||||
@ -11,7 +11,9 @@ This section contains a list of the Python modules that are used to extend the v
|
||||
../ref/auth/all/index
|
||||
../ref/beacons/all/index
|
||||
../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
|
||||
|
||||
@ -6,7 +6,7 @@ The Salt Fileserver and Client
|
||||
Introduction
|
||||
------------
|
||||
|
||||
Salt has a modular fileserver, and mulitple client classes which are used to
|
||||
Salt has a modular fileserver, and multiple client classes which are used to
|
||||
interact with it. This page serves as a developer's reference, to help explain
|
||||
how the fileserver and clients both work.
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
@ -186,7 +187,7 @@ execution modules
|
||||
iwtools
|
||||
jboss7
|
||||
jboss7_cli
|
||||
jenkins
|
||||
jenkinsmod
|
||||
junos
|
||||
k8s
|
||||
kapacitor
|
||||
@ -200,6 +201,7 @@ execution modules
|
||||
layman
|
||||
ldap3
|
||||
ldapmod
|
||||
libcloud_dns
|
||||
linux_acl
|
||||
linux_ip
|
||||
linux_lvm
|
||||
|
||||
@ -1,5 +0,0 @@
|
||||
salt.modules.cytest module
|
||||
==========================
|
||||
|
||||
.. automodule:: salt.modules.cytest
|
||||
:members:
|
||||
@ -1,5 +0,0 @@
|
||||
salt.modules.jenkins module
|
||||
===========================
|
||||
|
||||
.. automodule:: salt.modules.jenkins
|
||||
:members:
|
||||
5
doc/ref/modules/all/salt.modules.jenkinsmod.rst
Normal file
5
doc/ref/modules/all/salt.modules.jenkinsmod.rst
Normal file
@ -0,0 +1,5 @@
|
||||
salt.modules.jenkinsmod module
|
||||
==============================
|
||||
|
||||
.. automodule:: salt.modules.jenkinsmod
|
||||
:members:
|
||||
@ -1,5 +1,5 @@
|
||||
salt.modules.napalm_network module
|
||||
===============================
|
||||
==================================
|
||||
|
||||
.. automodule:: salt.modules.napalm_network
|
||||
:members:
|
||||
|
||||
@ -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)``
|
||||
|
||||
@ -33,7 +33,3 @@ Execution Module Used for
|
||||
:py:mod:`~salt.modules.win_service` Windows
|
||||
====================================== ========================================
|
||||
|
||||
|
|
||||
|
||||
.. automodule:: salt.modules.service
|
||||
:members:
|
||||
|
||||
@ -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:
|
||||
|
||||
|
||||
@ -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
|
||||
@ -376,6 +377,22 @@ The above example will force the minion to use the :py:mod:`systemd
|
||||
|
||||
.. __: https://github.com/saltstack/salt/issues/new
|
||||
|
||||
Logging Restrictions
|
||||
--------------------
|
||||
|
||||
As a rule, logging should not be done anywhere in a Salt module before it is
|
||||
loaded. This rule apples to all code that would run before the ``__virtual__()``
|
||||
function, as well as the code within the ``__virtual__()`` function itself.
|
||||
|
||||
If logging statements are made before the virtual function determines if
|
||||
the module should be loaded, then those logging statements will be called
|
||||
repeatedly. This clutters up log files unnecessarily.
|
||||
|
||||
Exceptions may be considered for logging statements made at the ``trace`` level.
|
||||
However, it is better to provide the necessary information by another means.
|
||||
One method is to :ref:`return error information <modules-error-info>` in the
|
||||
``__virtual__()`` function.
|
||||
|
||||
.. _modules-virtual-name:
|
||||
|
||||
``__virtualname__``
|
||||
@ -465,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.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
================
|
||||
=================
|
||||
salt.proxy.napalm
|
||||
================
|
||||
=================
|
||||
|
||||
.. automodule:: salt.proxy.napalm
|
||||
:members:
|
||||
|
||||
@ -10,9 +10,10 @@ to have access to execute select salt commands on minions from the master.
|
||||
The publisher ACL system is configured in the master configuration file via the
|
||||
``publisher_acl`` configuration option. Under the ``publisher_acl``
|
||||
configuration option the users open to send commands are specified and then a
|
||||
list of regular expressions which specify the minion functions which will be
|
||||
made available to specified user. This configuration is much like the ``peer``
|
||||
configuration:
|
||||
list of the minion functions which will be made available to specified user.
|
||||
Both users and functions could be specified by exact match, shell glob or
|
||||
regular expression. This configuration is much like the :ref:`external_auth
|
||||
<acl-eauth>` configuration:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -25,9 +26,19 @@ configuration:
|
||||
- web*:
|
||||
- test.*
|
||||
- pkg.*
|
||||
# Allow managers to use saltutil module functions
|
||||
manager_.*:
|
||||
# Allow admin and managers to use saltutil module functions
|
||||
admin|manager_.*:
|
||||
- saltutil.*
|
||||
# Allow users to use only my_mod functions on "web*" minions with specific arguments.
|
||||
user_.*:
|
||||
- web*:
|
||||
- 'my_mod.*':
|
||||
args:
|
||||
- 'a.*'
|
||||
- 'b.*'
|
||||
kwargs:
|
||||
'kwa': 'kwa.*'
|
||||
'kwb': 'kwb'
|
||||
|
||||
Permission Issues
|
||||
-----------------
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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::
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
======------============
|
||||
========================
|
||||
salt.states.rbac_solaris
|
||||
========================
|
||||
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
.. _compiler-ordering:
|
||||
|
||||
=====================================
|
||||
Understanding State Compiler Ordering
|
||||
=====================================
|
||||
|
||||
@ -12,7 +12,7 @@ option to your state declaration:
|
||||
service.running:
|
||||
- parallel: True
|
||||
|
||||
Now ``nginx`` will be started in a seperate process from the normal state run
|
||||
Now ``nginx`` will be started in a separate process from the normal state run
|
||||
and will therefore not block additional states.
|
||||
|
||||
Parallel States and Requisites
|
||||
@ -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:
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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)``
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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",
|
||||
|
||||
@ -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
|
||||
|
||||
@ -1019,7 +1019,7 @@ so:-
|
||||
- AndThirdSecurityGroup
|
||||
|
||||
Note that 'subnetid' takes precedence over 'subnetname', but 'securitygroupid'
|
||||
and 'securitygroupname' are merged toghether to generate a single list for
|
||||
and 'securitygroupname' are merged together to generate a single list for
|
||||
SecurityGroups of instances.
|
||||
|
||||
Specifying interface properties
|
||||
|
||||
@ -156,7 +156,7 @@ security_group
|
||||
~~~~~~~~~~~~~~
|
||||
.. versionadded:: next-release
|
||||
|
||||
You can specifiy a list of security groups (by name or id) that should be
|
||||
You can specify a list of security groups (by name or id) that should be
|
||||
assigned to the VM.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -257,4 +257,4 @@ This has also been tested to work with pipes, if needed:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
script_args: | head
|
||||
script_args: '| head'
|
||||
|
||||
@ -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
|
||||
========
|
||||
|
||||
@ -44,7 +44,7 @@ at ``/etc/salt/cloud.profiles`` or in the ``/etc/salt/cloud.profiles.d/`` direct
|
||||
|
||||
linode_1024:
|
||||
provider: my-linode-config
|
||||
size: Linode 2048
|
||||
size: Linode 2GB
|
||||
image: CentOS 7
|
||||
location: London, England, UK
|
||||
|
||||
@ -77,12 +77,14 @@ command:
|
||||
----------
|
||||
linode:
|
||||
----------
|
||||
Linode 1024:
|
||||
Linode 2GB:
|
||||
----------
|
||||
AVAIL:
|
||||
----------
|
||||
10:
|
||||
500
|
||||
11:
|
||||
500
|
||||
2:
|
||||
500
|
||||
3:
|
||||
@ -100,11 +102,19 @@ command:
|
||||
CORES:
|
||||
1
|
||||
DISK:
|
||||
24
|
||||
50
|
||||
HOURLY:
|
||||
0.015
|
||||
LABEL:
|
||||
Linode 1024
|
||||
Linode 2GB
|
||||
PLANID:
|
||||
2
|
||||
PRICE:
|
||||
10.0
|
||||
RAM:
|
||||
2048
|
||||
XFER:
|
||||
2000
|
||||
...SNIP...
|
||||
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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 ...
|
||||
|
||||
@ -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
|
||||
===================
|
||||
|
||||
@ -28,8 +28,6 @@ The Virtualbox cloud module just needs to use the virtualbox driver for now. Vir
|
||||
driver: virtualbox
|
||||
|
||||
|
||||
.. _vmware-cloud-profile:
|
||||
|
||||
Profiles
|
||||
========
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
@ -127,24 +127,24 @@ the following userdata example:
|
||||
$SourceStoreScope = 'LocalMachine'
|
||||
$SourceStorename = 'Remote Desktop'
|
||||
|
||||
$SourceStore = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Store -ArgumentList $SourceStorename, $SourceStoreScope
|
||||
$SourceStore = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Store -ArgumentList $SourceStorename, $SourceStoreScope
|
||||
$SourceStore.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadOnly)
|
||||
|
||||
$cert = $SourceStore.Certificates | Where-Object -FilterScript {
|
||||
$cert = $SourceStore.Certificates | Where-Object -FilterScript {
|
||||
$_.subject -like '*'
|
||||
}
|
||||
|
||||
$DestStoreScope = 'LocalMachine'
|
||||
$DestStoreName = 'My'
|
||||
|
||||
$DestStore = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Store -ArgumentList $DestStoreName, $DestStoreScope
|
||||
$DestStore = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Store -ArgumentList $DestStoreName, $DestStoreScope
|
||||
$DestStore.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)
|
||||
$DestStore.Add($cert)
|
||||
|
||||
$SourceStore.Close()
|
||||
$DestStore.Close()
|
||||
|
||||
winrm create winrm/config/listener?Address=*+Transport=HTTPS `@`{Hostname=`"($certId)`"`;CertificateThumbprint=`"($cert.Thumbprint)`"`}
|
||||
winrm create winrm/config/listener?Address=*+Transport=HTTPS `@`{CertificateThumbprint=`"($cert.Thumbprint)`"`}
|
||||
|
||||
Restart-Service winrm
|
||||
</powershell>
|
||||
|
||||
@ -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
|
||||
|
||||
@ -60,7 +60,7 @@ Fork a Repo Guide_>`_ and is well worth reading.
|
||||
isolated into separate branches.
|
||||
|
||||
If you're working on a bug or documentation fix, create your branch from
|
||||
the oldest release branch that contains the bug or requires the documentation
|
||||
the oldest **supported** main release branch that contains the bug or requires the documentation
|
||||
update. See :ref:`Which Salt Branch? <which-salt-branch>`.
|
||||
|
||||
.. code-block:: bash
|
||||
@ -212,8 +212,11 @@ There are three different kinds of branches in use: develop, main release
|
||||
branches, and dot release branches.
|
||||
|
||||
- All feature work should go into the ``develop`` branch.
|
||||
- Bug fixes and documentation changes should go into the oldest supported
|
||||
**main** release branch affected by the the bug or documentation change.
|
||||
- Bug fixes and documentation changes should go into the oldest **supported
|
||||
main** release branch affected by the the bug or documentation change (you
|
||||
can use the blame button in github to figure out when the bug was introduced).
|
||||
Supported releases are the last 2 releases. For example, if the latest release
|
||||
is 2018.3, the last two release are 2018.3 and 2017.7.
|
||||
Main release branches are named after a year and month, such as
|
||||
``2016.11`` and ``2017.7``.
|
||||
- Hot fixes, as determined by SaltStack's release team, should be submitted
|
||||
@ -223,7 +226,7 @@ branches, and dot release branches.
|
||||
.. note::
|
||||
|
||||
GitHub will open pull requests against Salt's main branch, ``develop``,
|
||||
byndefault. Be sure to check which branch is selected when creating the
|
||||
by default. Be sure to check which branch is selected when creating the
|
||||
pull request.
|
||||
|
||||
The Develop Branch
|
||||
@ -247,7 +250,7 @@ Main Release Branches
|
||||
=====================
|
||||
|
||||
The current release branch is the most recent stable release. Pull requests
|
||||
containing bug fixes or documentation changes should be made against the main
|
||||
containing bug fixes or documentation changes should be made against the oldest supported main
|
||||
release branch that is affected.
|
||||
|
||||
The branch name will be a date-based name such as ``2016.11``.
|
||||
|
||||
@ -212,8 +212,9 @@ on GitHub.
|
||||
repository in your own account on GitHub and notify a SaltStack employee
|
||||
when it is ready. We will add you to the contributors team on the
|
||||
`saltstack-formulas`_ organization and help you transfer the repository
|
||||
over. Ping a SaltStack employee on IRC (``#salt`` on Freenode) or send an
|
||||
email to the `salt-users`_ mailing list.
|
||||
over. Ping a SaltStack employee on IRC (``#salt`` on Freenode), join the
|
||||
``#formulas`` channel on the `salt-slack`_ or send an email to the
|
||||
`salt-users`_ mailing list.
|
||||
|
||||
There are a lot of repositories in that organization! Team members can
|
||||
manage which repositories they are subscribed to on GitHub's watching page:
|
||||
@ -225,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.
|
||||
@ -447,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', []) %}
|
||||
|
||||
@ -464,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 ---- #}
|
||||
|
||||
@ -505,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 ---- #}
|
||||
|
||||
@ -599,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``:
|
||||
|
||||
@ -651,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 }}:
|
||||
@ -671,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:
|
||||
@ -768,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 %}
|
||||
|
||||
@ -962,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(
|
||||
@ -981,10 +985,10 @@ The :py:func:`file.serialize <salt.states.file.serialize>` state can provide a
|
||||
shorthand for creating some files from data structures. There are also many
|
||||
examples within Salt Formulas of creating one-off "serializers" (often as Jinja
|
||||
macros) that reformat a data structure to a specific config file format. For
|
||||
example, `Nginx vhosts`__ or the `php.ini`__
|
||||
example, look at the`Nginx vhosts`_ states or the `php.ini`_ file template.
|
||||
|
||||
__: https://github.com/saltstack-formulas/nginx-formula/blob/5cad4512/nginx/ng/vhosts_config.sls
|
||||
__: https://github.com/saltstack-formulas/php-formula/blob/82e2cd3a/php/ng/files/php.ini
|
||||
.. _`Nginx vhosts`: https://github.com/saltstack-formulas/nginx-formula/blob/5cad4512/nginx/ng/vhosts_config.sls
|
||||
.. _`php.ini`: https://github.com/saltstack-formulas/php-formula/blob/82e2cd3a/php/ng/files/php.ini
|
||||
|
||||
Environment specific information
|
||||
................................
|
||||
@ -997,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 %}
|
||||
@ -1056,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:
|
||||
@ -1234,7 +1238,7 @@ target platform, and any other installation or usage instructions or tips.
|
||||
|
||||
A sample skeleton for the ``README.rst`` file:
|
||||
|
||||
.. code-block:: rest
|
||||
.. code-block:: restructuredtext
|
||||
|
||||
===
|
||||
foo
|
||||
@ -1242,10 +1246,10 @@ A sample skeleton for the ``README.rst`` file:
|
||||
|
||||
Install and configure the FOO service.
|
||||
|
||||
.. note::
|
||||
**NOTE**
|
||||
|
||||
See the full `Salt Formulas installation and usage instructions
|
||||
<http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html>`_.
|
||||
See the full `Salt Formulas installation and usage instructions
|
||||
<https://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html>`_.
|
||||
|
||||
Available states
|
||||
================
|
||||
@ -1274,7 +1278,7 @@ A sample skeleton for the `CHANGELOG.rst` file:
|
||||
|
||||
:file:`CHANGELOG.rst`:
|
||||
|
||||
.. code-block:: rest
|
||||
.. code-block:: restructuredtext
|
||||
|
||||
foo formula
|
||||
===========
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -8,7 +8,7 @@ Developing Salt
|
||||
|
||||
*
|
||||
extend/index
|
||||
tests/index
|
||||
tests/*
|
||||
raet/index
|
||||
git/index
|
||||
conventions/index
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -436,7 +436,7 @@ external resource, like a cloud virtual machine. This decorator is not normally
|
||||
used by developers outside of the Salt core team.
|
||||
|
||||
`@destructiveTest` -- Marks a test as potentially destructive. It will not be run
|
||||
by the test runner unles the ``-run-destructive`` test is expressly passed.
|
||||
by the test runner unless the ``-run-destructive`` test is expressly passed.
|
||||
|
||||
`@requires_network` -- Requires a network connection for the test to operate
|
||||
successfully. If a network connection is not detected, the test will not run.
|
||||
|
||||
@ -98,7 +98,7 @@ Mocking Loader Modules
|
||||
Salt loader modules use a series of globally available dunder variables,
|
||||
``__salt__``, ``__opts__``, ``__pillar__``, etc. To facilitate testing these
|
||||
modules a mixin class was created, ``LoaderModuleMockMixin`` which can be found
|
||||
in ``tests/support/mixins.py``. The reason for the existance of this class is
|
||||
in ``tests/support/mixins.py``. The reason for the existence of this class is
|
||||
because historiclly and because it was easier, one would add these dunder
|
||||
variables directly on the imported module. This however, introduces unexpected
|
||||
behavior when running the full test suite since those attributes would not be
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -27,12 +27,13 @@ in the master configuration file and uses the :ref:`access control system
|
||||
- 'web*':
|
||||
- test.*
|
||||
- network.*
|
||||
steve:
|
||||
steve|admin.*:
|
||||
- .*
|
||||
|
||||
The above configuration allows the user ``thatch`` to execute functions
|
||||
in the test and network modules on the minions that match the web* target.
|
||||
User ``steve`` is given unrestricted access to minion commands.
|
||||
The above configuration allows the user ``thatch`` to execute functions in the
|
||||
test and network modules on the minions that match the web* target. User
|
||||
``steve`` and the users whose logins start with ``admin``, are granted
|
||||
unrestricted access to minion commands.
|
||||
|
||||
Salt respects the current PAM configuration in place, and uses the 'login'
|
||||
service to authenticate.
|
||||
@ -71,8 +72,8 @@ Matching syntax
|
||||
---------------
|
||||
|
||||
The structure of the ``external_auth`` dictionary can take the following
|
||||
shapes. Function matches are regular expressions; minion matches are compound
|
||||
targets.
|
||||
shapes. User and function matches are exact matches, shell glob patterns or
|
||||
regular expressions; minion matches are compound targets.
|
||||
|
||||
By user:
|
||||
|
||||
@ -122,8 +123,8 @@ Positional arguments or keyword arguments to functions can also be whitelisted.
|
||||
- '*':
|
||||
- 'my_mod.*':
|
||||
args:
|
||||
- 'a.*'
|
||||
- 'b.*'
|
||||
- 'a.*'
|
||||
- 'b.*'
|
||||
kwargs:
|
||||
'kwa': 'kwa.*'
|
||||
'kwb': 'kwb'
|
||||
|
||||
@ -7,6 +7,8 @@ Salt Master Events
|
||||
These events are fired on the Salt Master event bus. This list is **not**
|
||||
comprehensive.
|
||||
|
||||
.. _event-master_auth:
|
||||
|
||||
Authentication events
|
||||
=====================
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user