mirror of
https://github.com/saltstack/salt.git
synced 2025-04-16 17:50:20 +00:00
Merge branch 'develop' into fix_couchbase_returner
This commit is contained in:
Mike Place
GitHub
commit
667bd38a69
1374 changed files with 66623 additions and 22240 deletions
60
.github/CODEOWNERS
vendored
Normal file
60
.github/CODEOWNERS
vendored
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
# SALTSTACK CODE OWNERS
|
||||
|
||||
# See https://help.github.com/articles/about-codeowners/
|
||||
# for more info about CODEOWNERS file
|
||||
|
||||
# Lines starting with '#' are comments.
|
||||
# Each line is a file pattern followed by one or more owners.
|
||||
|
||||
# See https://help.github.com/articles/about-codeowners/
|
||||
# for more info about the CODEOWNERS file
|
||||
|
||||
# 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/client/* @saltstack/team-core
|
||||
salt/config/* @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/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
|
||||
|
||||
# Team Network
|
||||
salt/proxy/ @saltstack/team-proxy
|
||||
|
||||
# Team SPM
|
||||
salt/cli/spm.py @saltstack/team-spm
|
||||
salt/spm/ @saltstack/team-spm
|
||||
|
||||
# Team SSH
|
||||
salt/cli/ssh.py @saltstack/team-ssh
|
||||
salt/client/ssh/ @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 Transport
|
||||
salt/transport/ @saltstack/team-transport
|
||||
salt/utils/zeromq.py @saltstack/team-transport
|
||||
|
||||
# Team Windows
|
||||
salt/**/*win* @saltstack/team-windows
|
||||
4
.github/stale.yml
vendored
4
.github/stale.yml
vendored
|
|
@ -1,8 +1,8 @@
|
|||
# Probot Stale configuration file
|
||||
|
||||
# Number of days of inactivity before an issue becomes stale
|
||||
# 1130 is approximately 3 years and 1 month
|
||||
daysUntilStale: 1130
|
||||
# 975 is approximately 2 years and 8 months
|
||||
daysUntilStale: 975
|
||||
|
||||
# Number of days of inactivity before a stale issue is closed
|
||||
daysUntilClose: 7
|
||||
|
|
|
|||
14
.mention-bot
14
.mention-bot
|
|
@ -1,5 +1,17 @@
|
|||
{
|
||||
"alwaysNotifyForPaths": [
|
||||
{
|
||||
"name": "ryan-lane",
|
||||
"files": ["salt/**/*boto*.py"],
|
||||
"skipTeamPrs": false
|
||||
},
|
||||
{
|
||||
"name": "tkwilliams",
|
||||
"files": ["salt/**/*boto*.py"],
|
||||
"skipTeamPrs": false
|
||||
}
|
||||
],
|
||||
"skipTitle": "Merge forward",
|
||||
"userBlacklist": ["cvrebert", "markusgattol", "olliewalsh"]
|
||||
"userBlacklist": ["cvrebert", "markusgattol", "olliewalsh", "basepi"]
|
||||
}
|
||||
|
||||
|
|
|
|||
12
README.rst
12
README.rst
|
|
@ -67,10 +67,11 @@ 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
|
||||
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
|
||||
Salted folks in your area of the world, or join `SaltConf`_, the SaltStack
|
||||
annual user conference held in Salt Lake City. Please visit the `SaltConf`_ site
|
||||
for details of our next conference. Also, 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
|
||||
|
||||
**SaltStack Training** - Get access to proprietary `SaltStack education
|
||||
offerings`_ through instructor-led training offered on-site, virtually or at
|
||||
|
|
@ -89,9 +90,8 @@ services`_ offerings.
|
|||
* LinkedIn Group - `<https://www.linkedin.com/groups/4877160>`_
|
||||
* Google+ - `<https://plus.google.com/b/112856352920437801867/+SaltStackInc/posts>`_
|
||||
|
||||
.. _SaltConf: http://www.youtube.com/user/saltstack
|
||||
.. _global community: http://www.meetup.com/pro/saltstack/
|
||||
.. _SaltConf16: http://saltconf.com/
|
||||
.. _SaltConf: 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/
|
||||
|
|
|
|||
11
conf/cloud
11
conf/cloud
|
|
@ -97,3 +97,14 @@
|
|||
#
|
||||
#delete_sshkeys: False
|
||||
|
||||
# Whether or not to include grains information in the /etc/salt/minion file
|
||||
# which is generated when the minion is provisioned. For example...
|
||||
# grains:
|
||||
# salt-cloud:
|
||||
# driver: ec2
|
||||
# provider: my_ec2:ec2
|
||||
# profile: micro_ec2
|
||||
#
|
||||
# Default: 'True'
|
||||
#
|
||||
#enable_cloud_grains: 'True'
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
# directory is identical.
|
||||
|
||||
#my-digitalocean-config:
|
||||
# driver: digital_ocean
|
||||
# driver: digitalocean
|
||||
# client_key: wFGEwgregeqw3435gDger
|
||||
# api_key: GDE43t43REGTrkilg43934t34qT43t4dgegerGEgg
|
||||
# location: New York 1
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
#my-digitalocean-config:
|
||||
# driver: digital_ocean
|
||||
# driver: digitalocean
|
||||
# client_key: wFGEwgregeqw3435gDger
|
||||
# api_key: GDE43t43REGTrkilg43934t34qT43t4dgegerGEgg
|
||||
# location: New York 1
|
||||
|
|
|
|||
23
conf/master
23
conf/master
|
|
@ -59,15 +59,14 @@
|
|||
|
||||
# Directory for custom modules. This directory can contain subdirectories for
|
||||
# each of Salt's module types such as "runners", "output", "wheel", "modules",
|
||||
# "states", "returners", etc.
|
||||
#extension_modules: <no default>
|
||||
# "states", "returners", "engines", "utils", etc.
|
||||
#extension_modules: /var/cache/salt/master/extmods
|
||||
|
||||
# Directory for custom modules. This directory can contain subdirectories for
|
||||
# each of Salt's module types such as "runners", "output", "wheel", "modules",
|
||||
# "states", "returners", "engines", etc.
|
||||
# "states", "returners", "engines", "utils", etc.
|
||||
# Like 'extension_modules' but can take an array of paths
|
||||
#module_dirs: <no default>
|
||||
# - /var/cache/salt/minion/extmods
|
||||
#module_dirs: []
|
||||
|
||||
# Verify and set permissions on configuration directories at startup:
|
||||
#verify_env: True
|
||||
|
|
@ -533,6 +532,9 @@
|
|||
# Add any additional locations to look for master runners:
|
||||
#runner_dirs: []
|
||||
|
||||
# Add any additional locations to look for master utils:
|
||||
#utils_dirs: []
|
||||
|
||||
# Enable Cython for master side modules:
|
||||
#cython_enable: False
|
||||
|
||||
|
|
@ -587,11 +589,12 @@
|
|||
# all data that has a result of True and no changes will be suppressed.
|
||||
#state_verbose: True
|
||||
|
||||
# The state_output setting changes if the output is the full multi line
|
||||
# output for each changed state if set to 'full', but if set to 'terse'
|
||||
# the output will be shortened to a single line. If set to 'mixed', the output
|
||||
# will be terse unless a state failed, in which case that output will be full.
|
||||
# If set to 'changes', the output will be full unless the state didn't change.
|
||||
# The state_output setting controls which results will be output full multi line
|
||||
# full, terse - each state will be full/terse
|
||||
# mixed - only states with errors will be full
|
||||
# changes - states with changes and errors will be full
|
||||
# full_id, mixed_id, changes_id and terse_id are also allowed;
|
||||
# when set, the state ID will be used as name in the output
|
||||
#state_output: full
|
||||
|
||||
# The state_output_diff setting changes whether or not the output from
|
||||
|
|
|
|||
17
conf/minion
17
conf/minion
|
|
@ -373,7 +373,7 @@
|
|||
# interface: eth0
|
||||
# cidr: '10.0.0.0/8'
|
||||
|
||||
# The number of seconds a mine update runs.
|
||||
# The number of minutes between mine updates.
|
||||
#mine_interval: 60
|
||||
|
||||
# Windows platforms lack posix IPC and must rely on slower TCP based inter-
|
||||
|
|
@ -635,9 +635,12 @@
|
|||
# all data that has a result of True and no changes will be suppressed.
|
||||
#state_verbose: True
|
||||
|
||||
# The state_output setting changes if the output is the full multi line
|
||||
# output for each changed state if set to 'full', but if set to 'terse'
|
||||
# the output will be shortened to a single line.
|
||||
# The state_output setting controls which results will be output full multi line
|
||||
# full, terse - each state will be full/terse
|
||||
# mixed - only states with errors will be full
|
||||
# changes - states with changes and errors will be full
|
||||
# full_id, mixed_id, changes_id and terse_id are also allowed;
|
||||
# when set, the state ID will be used as name in the output
|
||||
#state_output: full
|
||||
|
||||
# The state_output_diff setting changes whether or not the output from
|
||||
|
|
@ -689,6 +692,12 @@
|
|||
# for a full explanation.
|
||||
#multiprocessing: True
|
||||
|
||||
# Limit the maximum amount of processes or threads created by salt-minion.
|
||||
# This is useful to avoid resource exhaustion in case the minion receives more
|
||||
# publications than it is able to handle, as it limits the number of spawned
|
||||
# processes or threads. -1 is the default and disables the limit.
|
||||
#process_count_max: -1
|
||||
|
||||
|
||||
##### Logging settings #####
|
||||
##########################################
|
||||
|
|
|
|||
|
|
@ -498,9 +498,12 @@
|
|||
# all data that has a result of True and no changes will be suppressed.
|
||||
#state_verbose: True
|
||||
|
||||
# The state_output setting changes if the output is the full multi line
|
||||
# output for each changed state if set to 'full', but if set to 'terse'
|
||||
# the output will be shortened to a single line.
|
||||
# The state_output setting controls which results will be output full multi line
|
||||
# full, terse - each state will be full/terse
|
||||
# mixed - only states with errors will be full
|
||||
# changes - states with changes and errors will be full
|
||||
# full_id, mixed_id, changes_id and terse_id are also allowed;
|
||||
# when set, the state ID will be used as name in the output
|
||||
#state_output: full
|
||||
|
||||
# The state_output_diff setting changes whether or not the output from
|
||||
|
|
|
|||
|
|
@ -560,11 +560,12 @@ syndic_user: salt
|
|||
# all data that has a result of True and no changes will be suppressed.
|
||||
#state_verbose: True
|
||||
|
||||
# The state_output setting changes if the output is the full multi line
|
||||
# output for each changed state if set to 'full', but if set to 'terse'
|
||||
# the output will be shortened to a single line. If set to 'mixed', the output
|
||||
# will be terse unless a state failed, in which case that output will be full.
|
||||
# If set to 'changes', the output will be full unless the state didn't change.
|
||||
# The state_output setting controls which results will be output full multi line
|
||||
# full, terse - each state will be full/terse
|
||||
# mixed - only states with errors will be full
|
||||
# changes - states with changes and errors will be full
|
||||
# full_id, mixed_id, changes_id and terse_id are also allowed;
|
||||
# when set, the state ID will be used as name in the output
|
||||
#state_output: full
|
||||
|
||||
# The state_output_diff setting changes whether or not the output from
|
||||
|
|
|
|||
|
|
@ -245,8 +245,8 @@ on_saltstack = 'SALT_ON_SALTSTACK' in os.environ
|
|||
project = 'Salt'
|
||||
|
||||
version = salt.version.__version__
|
||||
latest_release = '2017.7.0' # latest release
|
||||
previous_release = '2016.11.6' # latest release from previous branch
|
||||
latest_release = '2017.7.1' # latest release
|
||||
previous_release = '2016.11.7' # latest release from previous branch
|
||||
previous_release_dir = '2016.11' # path on web server for previous branch
|
||||
next_release = '' # next release
|
||||
next_release_dir = '' # path on web server for next release branch
|
||||
|
|
@ -258,8 +258,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 = 'develop' # latest, previous, develop, next
|
||||
release = version # version, latest_release, previous_release
|
||||
# < --- END do not merge these settings to other branches END ---> #
|
||||
|
||||
# Set google custom search engine
|
||||
|
|
|
|||
|
|
@ -325,7 +325,7 @@ 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'
|
||||
|
|
|
|||
|
|
@ -10795,6 +10795,7 @@ cmd_whitelist_glob:
|
|||
.UNINDENT
|
||||
.UNINDENT
|
||||
.SS Thread Settings
|
||||
.SS \fBmultiprocessing\fP
|
||||
.sp
|
||||
Default: \fBTrue\fP
|
||||
.sp
|
||||
|
|
|
|||
|
|
@ -19,5 +19,4 @@ auth modules
|
|||
pki
|
||||
rest
|
||||
sharedsecret
|
||||
stormpath
|
||||
yubico
|
||||
|
|
|
|||
|
|
@ -1,6 +0,0 @@
|
|||
===================
|
||||
salt.auth.stormpath
|
||||
===================
|
||||
|
||||
.. automodule:: salt.auth.stormpath
|
||||
:members:
|
||||
|
|
@ -22,6 +22,7 @@ beacon modules
|
|||
load
|
||||
log
|
||||
memusage
|
||||
napalm_beacon
|
||||
network_info
|
||||
network_settings
|
||||
pkg
|
||||
|
|
|
|||
6
doc/ref/beacons/all/salt.beacons.napalm_beacon.rst
Normal file
6
doc/ref/beacons/all/salt.beacons.napalm_beacon.rst
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
==========================
|
||||
salt.beacons.napalm_beacon
|
||||
==========================
|
||||
|
||||
.. automodule:: salt.beacons.napalm_beacon
|
||||
:members:
|
||||
|
|
@ -33,6 +33,10 @@ Output Options
|
|||
|
||||
Write the output to the specified file.
|
||||
|
||||
.. option:: --out-file-append, --output-file-append
|
||||
|
||||
Append the output to the specified file.
|
||||
|
||||
.. option:: --no-color
|
||||
|
||||
Disable all colored output
|
||||
|
|
@ -46,3 +50,14 @@ Output Options
|
|||
|
||||
``green`` denotes success, ``red`` denotes failure, ``blue`` denotes
|
||||
changes and success and ``yellow`` denotes a expected future change in configuration.
|
||||
|
||||
.. option:: --state-output=STATE_OUTPUT, --state_output=STATE_OUTPUT
|
||||
|
||||
Override the configured state_output value for minion
|
||||
output. One of 'full', 'terse', 'mixed', 'changes' or
|
||||
'filter'. Default: 'none'.
|
||||
|
||||
.. option:: --state-verbose=STATE_VERBOSE, --state_verbose=STATE_VERBOSE
|
||||
|
||||
Override the configured state_verbose value for minion
|
||||
output. Set to True or False. Default: none.
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@ Query Options
|
|||
.. versionadded:: 2014.7.0
|
||||
|
||||
Display a list of configured profiles. Pass in a cloud provider to view
|
||||
the provider's associated profiles, such as ``digital_ocean``, or pass in
|
||||
the provider's associated profiles, such as ``digitalocean``, or pass in
|
||||
``all`` to list all the configured profiles.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -39,6 +39,13 @@ specified target expression.
|
|||
desitination will be assumed to be a directory. Finally, recursion is now
|
||||
supported, allowing for entire directories to be copied.
|
||||
|
||||
.. versionchanged:: 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
|
||||
``-C`` or ``--chunked`` CLI arguments. Note that compression, recursive
|
||||
copying, and support for copying large files is only available in chunked
|
||||
mode.
|
||||
|
||||
Options
|
||||
=======
|
||||
|
||||
|
|
@ -56,9 +63,16 @@ Options
|
|||
.. include:: _includes/target-selection.rst
|
||||
|
||||
|
||||
.. option:: -C, --chunked
|
||||
|
||||
Use new chunked mode to copy files. This mode supports large files, recursive
|
||||
directories copying and compression.
|
||||
|
||||
.. versionadded:: 2016.11.7,2017.7.2
|
||||
|
||||
.. option:: -n, --no-compression
|
||||
|
||||
Disable gzip compression.
|
||||
Disable gzip compression in chunked mode.
|
||||
|
||||
.. versionadded:: 2016.3.7,2016.11.6,2017.7.0
|
||||
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ Options
|
|||
|
||||
Pass in an external authentication medium to validate against. The
|
||||
credentials will be prompted for. The options are `auto`,
|
||||
`keystone`, `ldap`, `pam`, and `stormpath`. Can be used with the -T
|
||||
`keystone`, `ldap`, and `pam`. Can be used with the -T
|
||||
option.
|
||||
|
||||
.. option:: -T, --make-token
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Full list of Salt Cloud modules
|
|||
aliyun
|
||||
azurearm
|
||||
cloudstack
|
||||
digital_ocean
|
||||
digitalocean
|
||||
dimensiondata
|
||||
ec2
|
||||
gce
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
===============================
|
||||
salt.cloud.clouds.digital_ocean
|
||||
salt.cloud.clouds.digitalocean
|
||||
===============================
|
||||
|
||||
.. automodule:: salt.cloud.clouds.digital_ocean
|
||||
.. automodule:: salt.cloud.clouds.digitalocean
|
||||
:members:
|
||||
6
doc/ref/clouds/all/salt.cloud.clouds.oneandone.rst
Normal file
6
doc/ref/clouds/all/salt.cloud.clouds.oneandone.rst
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
===========================
|
||||
salt.cloud.clouds.oneandone
|
||||
===========================
|
||||
|
||||
.. automodule:: salt.cloud.clouds.oneandone
|
||||
:members:
|
||||
|
|
@ -183,8 +183,8 @@ The directory to store the pki authentication keys.
|
|||
|
||||
Directory for custom modules. This directory can contain subdirectories for
|
||||
each of Salt's module types such as ``runners``, ``output``, ``wheel``,
|
||||
``modules``, ``states``, ``returners``, ``engines``, etc. This path is appended to
|
||||
:conf_master:`root_dir`.
|
||||
``modules``, ``states``, ``returners``, ``engines``, ``utils``, etc.
|
||||
This path is appended to :conf_master:`root_dir`.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -234,6 +234,7 @@ Valid options:
|
|||
- clouds
|
||||
- tops
|
||||
- roster
|
||||
- tokens
|
||||
|
||||
.. conf_master:: module_dirs
|
||||
|
||||
|
|
@ -1730,6 +1731,22 @@ Set additional directories to search for runner modules.
|
|||
runner_dirs:
|
||||
- /var/lib/salt/runners
|
||||
|
||||
.. conf_master:: utils_dirs
|
||||
|
||||
``utils_dirs``
|
||||
---------------
|
||||
|
||||
.. versionadded:: Oxygen
|
||||
|
||||
Default: ``[]``
|
||||
|
||||
Set additional directories to search for util modules.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
utils_dirs:
|
||||
- /var/lib/salt/utils
|
||||
|
||||
.. conf_master:: cython_enable
|
||||
|
||||
``cython_enable``
|
||||
|
|
@ -1994,11 +2011,14 @@ output for states that failed or states that have changes.
|
|||
|
||||
Default: ``full``
|
||||
|
||||
The state_output setting changes if the output is the full multi line
|
||||
output for each changed state if set to 'full', but if set to 'terse'
|
||||
the output will be shortened to a single line. If set to 'mixed', the output
|
||||
will be terse unless a state failed, in which case that output will be full.
|
||||
If set to 'changes', the output will be full unless the state didn't change.
|
||||
The state_output setting controls which results will be output full multi line:
|
||||
|
||||
* ``full``, ``terse`` - each state will be full/terse
|
||||
* ``mixed`` - only states with errors will be full
|
||||
* ``changes`` - states with changes and errors will be full
|
||||
|
||||
``full_id``, ``mixed_id``, ``changes_id`` and ``terse_id`` are also allowed;
|
||||
when set, the state ID will be used as name in the output.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -3770,7 +3790,7 @@ they were created by a different master.
|
|||
Default: ``True``
|
||||
|
||||
Normally, when processing :ref:`git_pillar remotes
|
||||
<git-pillar-2015-8-0-and-later>`, if more than one repo under the same ``git``
|
||||
<git-pillar-configuration>`, if more than one repo under the same ``git``
|
||||
section in the ``ext_pillar`` configuration refers to the same pillar
|
||||
environment, then each repo in a given environment will have access to the
|
||||
other repos' files to be referenced in their top files. However, it may be
|
||||
|
|
@ -4158,7 +4178,9 @@ information.
|
|||
|
||||
.. code-block:: yaml
|
||||
|
||||
reactor: []
|
||||
reactor:
|
||||
- 'salt/minion/*/start':
|
||||
- salt://reactor/startup_tasks.sls
|
||||
|
||||
.. conf_master:: reactor_refresh_interval
|
||||
|
||||
|
|
|
|||
|
|
@ -706,7 +706,7 @@ Note these can be defined in the pillar for a minion as well.
|
|||
|
||||
Default: ``60``
|
||||
|
||||
The number of seconds a mine update runs.
|
||||
The number of minutes between mine updates.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -1664,15 +1664,19 @@ output for states that failed or states that have changes.
|
|||
|
||||
Default: ``full``
|
||||
|
||||
The state_output setting changes if the output is the full multi line
|
||||
output for each changed state if set to 'full', but if set to 'terse'
|
||||
the output will be shortened to a single line.
|
||||
The state_output setting controls which results will be output full multi line:
|
||||
|
||||
* ``full``, ``terse`` - each state will be full/terse
|
||||
* ``mixed`` - only states with errors will be full
|
||||
* ``changes`` - states with changes and errors will be full
|
||||
|
||||
``full_id``, ``mixed_id``, ``changes_id`` and ``terse_id`` are also allowed;
|
||||
when set, the state ID will be used as name in the output.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
state_output: full
|
||||
|
||||
|
||||
.. conf_minion:: state_output_diff
|
||||
|
||||
``state_output_diff``
|
||||
|
|
@ -2113,6 +2117,41 @@ It will be interpreted as megabytes.
|
|||
|
||||
file_recv_max_size: 100
|
||||
|
||||
.. conf_minion:: pass_to_ext_pillars
|
||||
|
||||
``pass_to_ext_pillars``
|
||||
-----------------------
|
||||
|
||||
Specify a list of configuration keys whose values are to be passed to
|
||||
external pillar functions.
|
||||
|
||||
Suboptions can be specified using the ':' notation (i.e. ``option:suboption``)
|
||||
|
||||
The values are merged and included in the ``extra_minion_data`` optional
|
||||
parameter of the external pillar function. The ``extra_minion_data`` parameter
|
||||
is passed only to the external pillar functions that have it explicitly
|
||||
specified in their definition.
|
||||
|
||||
If the config contains
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
opt1: value1
|
||||
opt2:
|
||||
subopt1: value2
|
||||
subopt2: value3
|
||||
|
||||
pass_to_ext_pillars:
|
||||
- opt1
|
||||
- opt2: subopt1
|
||||
|
||||
the ``extra_minion_data`` parameter will be
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
{'opt1': 'value1',
|
||||
'opt2': {'subopt1': 'value2'}}
|
||||
|
||||
Security Settings
|
||||
=================
|
||||
|
||||
|
|
@ -2369,11 +2408,14 @@ Thread Settings
|
|||
|
||||
.. conf_minion:: multiprocessing
|
||||
|
||||
``multiprocessing``
|
||||
-------
|
||||
|
||||
Default: ``True``
|
||||
|
||||
If `multiprocessing` is enabled when a minion receives a
|
||||
If ``multiprocessing`` is enabled when a minion receives a
|
||||
publication a new process is spawned and the command is executed therein.
|
||||
Conversely, if `multiprocessing` is disabled the new publication will be run
|
||||
Conversely, if ``multiprocessing`` is disabled the new publication will be run
|
||||
executed in a thread.
|
||||
|
||||
|
||||
|
|
@ -2381,6 +2423,23 @@ executed in a thread.
|
|||
|
||||
multiprocessing: True
|
||||
|
||||
.. conf_minion:: process_count_max
|
||||
|
||||
``process_count_max``
|
||||
-------
|
||||
|
||||
.. versionadded:: Oxygen
|
||||
|
||||
Default: ``-1``
|
||||
|
||||
Limit the maximum amount of processes or threads created by ``salt-minion``.
|
||||
This is useful to avoid resource exhaustion in case the minion receives more
|
||||
publications than it is able to handle, as it limits the number of spawned
|
||||
processes or threads. ``-1`` is the default and disables the limit.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
process_count_max: -1
|
||||
|
||||
.. _minion-logging-settings:
|
||||
|
||||
|
|
|
|||
|
|
@ -118,3 +118,53 @@ has to be closed after every command.
|
|||
.. code-block:: yaml
|
||||
|
||||
proxy_always_alive: False
|
||||
|
||||
``proxy_merge_pillar_in_opts``
|
||||
------------------------------
|
||||
|
||||
.. versionadded:: 2017.7.3
|
||||
|
||||
Default: ``False``.
|
||||
|
||||
Wheter 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.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
proxy_merge_pillar_in_opts: True
|
||||
|
||||
``proxy_deep_merge_pillar_in_opts``
|
||||
-----------------------------------
|
||||
|
||||
.. versionadded:: 2017.7.3
|
||||
|
||||
Default: ``False``.
|
||||
|
||||
Deep merge of pillar data into configuration opts.
|
||||
This option is evaluated only when :conf_proxy:`proxy_merge_pillar_in_opts` is
|
||||
enabled.
|
||||
|
||||
``proxy_merge_pillar_in_opts_strategy``
|
||||
---------------------------------------
|
||||
|
||||
.. versionadded:: 2017.7.3
|
||||
|
||||
Default: ``smart``.
|
||||
|
||||
The strategy used when merging pillar configuration into opts.
|
||||
This option is evaluated only when :conf_proxy:`proxy_merge_pillar_in_opts` is
|
||||
enabled.
|
||||
|
||||
``proxy_mines_pillar``
|
||||
----------------------
|
||||
|
||||
.. versionadded:: 2017.7.3
|
||||
|
||||
Default: ``True``.
|
||||
|
||||
Allow enabling mine details using pillar data. This evaluates the mine
|
||||
configuration under the pillar, for the following regular minion options that
|
||||
are also equally available on the proxy minion: :conf_minion:`mine_interval`,
|
||||
and :conf_minion:`mine_functions`.
|
||||
|
|
|
|||
|
|
@ -44,6 +44,7 @@ execution modules
|
|||
boto_apigateway
|
||||
boto_asg
|
||||
boto_cfn
|
||||
boto_cloudfront
|
||||
boto_cloudtrail
|
||||
boto_cloudwatch
|
||||
boto_cloudwatch_event
|
||||
|
|
@ -97,6 +98,7 @@ execution modules
|
|||
cytest
|
||||
daemontools
|
||||
data
|
||||
datadog_api
|
||||
ddns
|
||||
deb_apache
|
||||
deb_postgres
|
||||
|
|
@ -197,6 +199,7 @@ execution modules
|
|||
keyboard
|
||||
keystone
|
||||
kmod
|
||||
kubernetes
|
||||
launchctl
|
||||
layman
|
||||
ldap3
|
||||
|
|
@ -324,6 +327,7 @@ execution modules
|
|||
ps
|
||||
publish
|
||||
puppet
|
||||
purefa
|
||||
pushbullet
|
||||
pushover_notify
|
||||
pw_group
|
||||
|
|
@ -398,7 +402,6 @@ execution modules
|
|||
state
|
||||
status
|
||||
statuspage
|
||||
stormpath
|
||||
supervisord
|
||||
suse_apache
|
||||
svn
|
||||
|
|
@ -416,6 +419,7 @@ execution modules
|
|||
test
|
||||
testinframod
|
||||
test_virtual
|
||||
textfsm_mod
|
||||
timezone
|
||||
tls
|
||||
tomcat
|
||||
|
|
|
|||
6
doc/ref/modules/all/salt.modules.boto_cloudfront.rst
Normal file
6
doc/ref/modules/all/salt.modules.boto_cloudfront.rst
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
============================
|
||||
salt.modules.boto_cloudfront
|
||||
============================
|
||||
|
||||
.. automodule:: salt.modules.boto_cloudfront
|
||||
:members:
|
||||
6
doc/ref/modules/all/salt.modules.datadog_api.rst
Normal file
6
doc/ref/modules/all/salt.modules.datadog_api.rst
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
========================
|
||||
salt.modules.datadog_api
|
||||
========================
|
||||
|
||||
.. automodule:: salt.modules.datadog_api
|
||||
:members:
|
||||
|
|
@ -13,7 +13,7 @@ salt.modules.kernelpkg
|
|||
Execution Module Used for
|
||||
============================================ ========================================
|
||||
:py:mod:`~salt.modules.kernelpkg_linux_apt` Debian/Ubuntu-based distros which use
|
||||
``apt-get(8)`` for package management
|
||||
``apt-get`` for package management
|
||||
:py:mod:`~salt.modules.kernelpkg_linux_yum` RedHat-based distros and derivatives
|
||||
using ``yum(8)`` or ``dnf(8)``
|
||||
using ``yum`` or ``dnf``
|
||||
============================================ ========================================
|
||||
|
|
|
|||
6
doc/ref/modules/all/salt.modules.kubernetes.rst
Normal file
6
doc/ref/modules/all/salt.modules.kubernetes.rst
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
=======================
|
||||
salt.modules.kubernetes
|
||||
=======================
|
||||
|
||||
.. automodule:: salt.modules.kubernetes
|
||||
:members:
|
||||
6
doc/ref/modules/all/salt.modules.purefa.rst
Normal file
6
doc/ref/modules/all/salt.modules.purefa.rst
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
===================
|
||||
salt.modules.purefa
|
||||
===================
|
||||
|
||||
.. automodule:: salt.modules.purefa
|
||||
:members:
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
======================
|
||||
salt.modules.stormpath
|
||||
======================
|
||||
|
||||
.. automodule:: salt.modules.stormpath
|
||||
:members:
|
||||
|
|
@ -3,4 +3,5 @@ salt.modules.test
|
|||
=================
|
||||
|
||||
.. automodule:: salt.modules.test
|
||||
:members:
|
||||
:members:
|
||||
:exclude-members: rand_str
|
||||
|
|
|
|||
5
doc/ref/modules/all/salt.modules.textfsm_mod.rst
Normal file
5
doc/ref/modules/all/salt.modules.textfsm_mod.rst
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
salt.modules.textfsm_mod module
|
||||
===============================
|
||||
|
||||
.. automodule:: salt.modules.textfsm_mod
|
||||
:members:
|
||||
|
|
@ -429,10 +429,33 @@ similar to the following:
|
|||
Confine this module to Mac OS with Homebrew.
|
||||
'''
|
||||
|
||||
if salt.utils.which('brew') and __grains__['os'] == 'MacOS':
|
||||
if salt.utils.path.which('brew') and __grains__['os'] == 'MacOS':
|
||||
return __virtualname__
|
||||
return False
|
||||
|
||||
The ``__virtual__()`` function can return a ``True`` or ``False`` boolean, a tuple,
|
||||
or a string. If it returns a ``True`` value, this ``__virtualname__`` module-level
|
||||
attribute can be set as seen in the above example. This is the string that the module
|
||||
should be referred to as.
|
||||
|
||||
When ``__virtual__()`` returns a tuple, the first item should be a boolean and the
|
||||
second should be a string. This is typically done when the module should not load. The
|
||||
first value of the tuple is ``False`` and the second is the error message to display
|
||||
for why the module did not load.
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
def __virtual__():
|
||||
'''
|
||||
Only load if git exists on the system
|
||||
'''
|
||||
if salt.utils.path.which('git') is None:
|
||||
return (False,
|
||||
'The git execution module cannot be loaded: git unavailable.')
|
||||
else:
|
||||
return True
|
||||
|
||||
Documentation
|
||||
=============
|
||||
|
|
|
|||
|
|
@ -25,6 +25,9 @@ configuration:
|
|||
- web*:
|
||||
- test.*
|
||||
- pkg.*
|
||||
# Allow managers to use saltutil module functions
|
||||
manager_.*:
|
||||
- saltutil.*
|
||||
|
||||
Permission Issues
|
||||
-----------------
|
||||
|
|
|
|||
|
|
@ -146,8 +146,10 @@ Here is a simple YAML renderer example:
|
|||
|
||||
import yaml
|
||||
from salt.utils.yamlloader import SaltYamlSafeLoader
|
||||
from salt.ext import six
|
||||
|
||||
def render(yaml_data, saltenv='', sls='', **kws):
|
||||
if not isinstance(yaml_data, basestring):
|
||||
if not isinstance(yaml_data, six.string_types):
|
||||
yaml_data = yaml_data.read()
|
||||
data = yaml.load(
|
||||
yaml_data,
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
salt.runners.auth module
|
||||
========================
|
||||
salt.runners.auth
|
||||
=================
|
||||
|
||||
.. automodule:: salt.runners.auth
|
||||
:members:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
salt.runners.digicertapi module
|
||||
===============================
|
||||
salt.runners.digicertapi
|
||||
========================
|
||||
|
||||
.. automodule:: salt.runners.digicertapi
|
||||
:members:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
salt.runners.event module
|
||||
=========================
|
||||
salt.runners.event
|
||||
==================
|
||||
|
||||
.. automodule:: salt.runners.event
|
||||
:members:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,11 @@
|
|||
salt.runners.mattermost module
|
||||
==============================
|
||||
salt.runners.mattermost
|
||||
=======================
|
||||
|
||||
**Note for 2017.7 releases!**
|
||||
|
||||
Due to the `salt.runners.config <https://github.com/saltstack/salt/blob/develop/salt/runners/config.py>`_ module not being available in this release series, importing the `salt.runners.config <https://github.com/saltstack/salt/blob/develop/salt/runners/config.py>`_ module from the develop branch is required to make this module work.
|
||||
|
||||
Ref: `Mattermost runner failing to retrieve config values due to unavailable config runner #43479 <https://github.com/saltstack/salt/issues/43479>`_
|
||||
|
||||
.. automodule:: salt.runners.mattermost
|
||||
:members:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
salt.runners.smartos_vmadm module
|
||||
=================================
|
||||
salt.runners.smartos_vmadm
|
||||
==========================
|
||||
|
||||
.. automodule:: salt.runners.smartos_vmadm
|
||||
:members:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
salt.runners.vault module
|
||||
=========================
|
||||
salt.runners.vault
|
||||
==================
|
||||
|
||||
.. automodule:: salt.runners.vault
|
||||
:members:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
salt.runners.venafiapi module
|
||||
=============================
|
||||
salt.runners.venafiapi
|
||||
======================
|
||||
|
||||
.. automodule:: salt.runners.venafiapi
|
||||
:members:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
salt.runners.vistara module
|
||||
===========================
|
||||
salt.runners.vistara
|
||||
====================
|
||||
|
||||
.. automodule:: salt.runners.vistara
|
||||
:members:
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ This example, simplified from the pkg state, shows how to create mod_aggregate f
|
|||
for chunk in chunks:
|
||||
# The state runtime uses "tags" to track completed jobs, it may
|
||||
# look familiar with the _|-
|
||||
tag = salt.utils.gen_state_tag(chunk)
|
||||
tag = __utils__['state.gen_tag'](chunk)
|
||||
if tag in running:
|
||||
# Already ran the pkg state, skip aggregation
|
||||
continue
|
||||
|
|
|
|||
|
|
@ -31,6 +31,7 @@ state modules
|
|||
boto_apigateway
|
||||
boto_asg
|
||||
boto_cfn
|
||||
boto_cloudfront
|
||||
boto_cloudtrail
|
||||
boto_cloudwatch_alarm
|
||||
boto_cloudwatch_event
|
||||
|
|
@ -136,6 +137,7 @@ state modules
|
|||
keyboard
|
||||
keystone
|
||||
kmod
|
||||
kubernetes
|
||||
layman
|
||||
ldap
|
||||
libcloud_dns
|
||||
|
|
@ -178,6 +180,7 @@ state modules
|
|||
netusers
|
||||
network
|
||||
netyang
|
||||
nfs_export
|
||||
nftables
|
||||
npm
|
||||
ntp
|
||||
|
|
@ -249,7 +252,6 @@ state modules
|
|||
stateconf
|
||||
status
|
||||
statuspage
|
||||
stormpath_account
|
||||
supervisord
|
||||
svn
|
||||
sysctl
|
||||
|
|
|
|||
6
doc/ref/states/all/salt.states.boto_cloudfront.rst
Normal file
6
doc/ref/states/all/salt.states.boto_cloudfront.rst
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
===========================
|
||||
salt.states.boto_cloudfront
|
||||
===========================
|
||||
|
||||
.. automodule:: salt.states.boto_cloudfront
|
||||
:members:
|
||||
6
doc/ref/states/all/salt.states.kubernetes.rst
Normal file
6
doc/ref/states/all/salt.states.kubernetes.rst
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
======================
|
||||
salt.states.kubernetes
|
||||
======================
|
||||
|
||||
.. automodule:: salt.states.kubernetes
|
||||
:members:
|
||||
6
doc/ref/states/all/salt.states.nfs_export.rst
Normal file
6
doc/ref/states/all/salt.states.nfs_export.rst
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
======================
|
||||
salt.states.nfs_export
|
||||
======================
|
||||
|
||||
.. automodule:: salt.states.nfs_export
|
||||
:members:
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
=============================
|
||||
salt.states.stormpath_account
|
||||
=============================
|
||||
|
||||
.. automodule:: salt.states.stormpath_account
|
||||
:members:
|
||||
|
|
@ -519,7 +519,8 @@ runas
|
|||
|
||||
.. versionadded:: 2017.7.0
|
||||
|
||||
The ``runas`` global option is used to set the user which will be used to run the command in the ``cmd.run`` module.
|
||||
The ``runas`` global option is used to set the user which will be used to run
|
||||
the command in the ``cmd.run`` module.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -532,6 +533,26 @@ The ``runas`` global option is used to set the user which will be used to run th
|
|||
|
||||
In the above state, the pip command run by ``cmd.run`` will be run by the daniel user.
|
||||
|
||||
runas_password
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 2017.7.2
|
||||
|
||||
The ``runas_password`` global option is used to set the password used by the
|
||||
runas global option. This is required by ``cmd.run`` on Windows when ``runas``
|
||||
is specified. It will be set when ``runas_password`` is defined in the state.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
run_script:
|
||||
cmd.run:
|
||||
- name: Powershell -NonInteractive -ExecutionPolicy Bypass -File C:\\Temp\\script.ps1
|
||||
- runas: frank
|
||||
- runas_password: supersecret
|
||||
|
||||
In the above state, the Powershell script run by ``cmd.run`` will be run by the
|
||||
frank user with the password ``supersecret``.
|
||||
|
||||
.. _requisites-require-in:
|
||||
.. _requisites-watch-in:
|
||||
.. _requisites-onchanges-in:
|
||||
|
|
|
|||
|
|
@ -135,21 +135,30 @@ A State Module must return a dict containing the following keys/values:
|
|||
``test=True``, and changes would have been made if the state was not run in
|
||||
test mode.
|
||||
|
||||
+--------------------+-----------+-----------+
|
||||
| | live mode | test mode |
|
||||
+====================+===========+===========+
|
||||
| no changes | ``True`` | ``True`` |
|
||||
+--------------------+-----------+-----------+
|
||||
| successful changes | ``True`` | ``None`` |
|
||||
+--------------------+-----------+-----------+
|
||||
| failed changes | ``False`` | ``None`` |
|
||||
+--------------------+-----------+-----------+
|
||||
+--------------------+-----------+------------------------+
|
||||
| | live mode | test mode |
|
||||
+====================+===========+========================+
|
||||
| no changes | ``True`` | ``True`` |
|
||||
+--------------------+-----------+------------------------+
|
||||
| successful changes | ``True`` | ``None`` |
|
||||
+--------------------+-----------+------------------------+
|
||||
| failed changes | ``False`` | ``False`` or ``None`` |
|
||||
+--------------------+-----------+------------------------+
|
||||
|
||||
.. note::
|
||||
|
||||
Test mode does not predict if the changes will be successful or not.
|
||||
Test mode does not predict if the changes will be successful or not,
|
||||
and hence the result for pending changes is usually ``None``.
|
||||
|
||||
- **comment:** A string containing a summary of the result.
|
||||
However, if a state is going to fail and this can be determined
|
||||
in test mode without applying the change, ``False`` can be returned.
|
||||
|
||||
- **comment:** A list of strings or a single string summarizing the result.
|
||||
Note that support for lists of strings is available as of Salt Oxygen.
|
||||
Lists of strings will be joined with newlines to form the final comment;
|
||||
this is useful to allow multiple comments from subparts of a state.
|
||||
Prefer to keep line lengths short (use multiple lines as needed),
|
||||
and end with punctuation (e.g. a period) to delimit multiple comments.
|
||||
|
||||
The return data can also, include the **pchanges** key, this stands for
|
||||
`predictive changes`. The **pchanges** key informs the State system what
|
||||
|
|
|
|||
|
|
@ -777,8 +777,6 @@ Stateconf
|
|||
stderr
|
||||
stdin
|
||||
stdout
|
||||
stormpath
|
||||
Stormpath
|
||||
str
|
||||
strftime
|
||||
subfolder
|
||||
|
|
|
|||
|
|
@ -253,9 +253,8 @@ in ``/etc/salt/master.d/reactor.conf``:
|
|||
|
||||
.. note::
|
||||
You can have only one top level ``reactor`` section, so if one already
|
||||
exists, add this code to the existing section. See :ref:`Understanding the
|
||||
Structure of Reactor Formulas <reactor-structure>` to learn more about
|
||||
reactor SLS syntax.
|
||||
exists, add this code to the existing section. See :ref:`here
|
||||
<reactor-sls>` to learn more about reactor SLS syntax.
|
||||
|
||||
|
||||
Start the Salt Master in Debug Mode
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Or you may specify a map which includes all VMs to perform the action on:
|
|||
|
||||
$ salt-cloud -a reboot -m /path/to/mapfile
|
||||
|
||||
The following is a list of actions currently supported by salt-cloud:
|
||||
The following is an example list of actions currently supported by ``salt-cloud``:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -36,5 +36,5 @@ The following is a list of actions currently supported by salt-cloud:
|
|||
- start
|
||||
- stop
|
||||
|
||||
Another useful reference for viewing more salt-cloud actions is the
|
||||
:ref:Salt Cloud Feature Matrix <salt-cloud-feature-matrix>
|
||||
Another useful reference for viewing more ``salt-cloud`` actions is the
|
||||
:ref:`Salt Cloud Feature Matrix <salt-cloud-feature-matrix>`.
|
||||
|
|
|
|||
|
|
@ -15,9 +15,7 @@ More information about Azure is located at `http://www.windowsazure.com/
|
|||
|
||||
Dependencies
|
||||
============
|
||||
* `Microsoft Azure SDK for Python <https://pypi.python.org/pypi/azure>`_ >= 2.0rc6
|
||||
* `Microsoft Azure Storage SDK for Python <https://pypi.python.org/pypi/azure-storage>`_ >= 0.32
|
||||
* The python-requests library, for Python < 2.7.9.
|
||||
* Azure Cli ```pip install 'azure-cli>=2.0.12'```
|
||||
* A Microsoft Azure account
|
||||
* `Salt <https://github.com/saltstack/salt>`_
|
||||
|
||||
|
|
|
|||
|
|
@ -146,24 +146,24 @@ library. The following two lines set up the imports:
|
|||
.. code-block:: python
|
||||
|
||||
from salt.cloud.libcloudfuncs import * # pylint: disable=W0614,W0401
|
||||
from salt.utils import namespaced_function
|
||||
import salt.utils
|
||||
|
||||
And then a series of declarations will make the necessary functions available
|
||||
within the cloud module.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
get_size = namespaced_function(get_size, globals())
|
||||
get_image = namespaced_function(get_image, globals())
|
||||
avail_locations = namespaced_function(avail_locations, globals())
|
||||
avail_images = namespaced_function(avail_images, globals())
|
||||
avail_sizes = namespaced_function(avail_sizes, globals())
|
||||
script = namespaced_function(script, globals())
|
||||
destroy = namespaced_function(destroy, globals())
|
||||
list_nodes = namespaced_function(list_nodes, globals())
|
||||
list_nodes_full = namespaced_function(list_nodes_full, globals())
|
||||
list_nodes_select = namespaced_function(list_nodes_select, globals())
|
||||
show_instance = namespaced_function(show_instance, globals())
|
||||
get_size = salt.utils.namespaced_function(get_size, globals())
|
||||
get_image = salt.utils.namespaced_function(get_image, globals())
|
||||
avail_locations = salt.utils.namespaced_function(avail_locations, globals())
|
||||
avail_images = salt.utils.namespaced_function(avail_images, globals())
|
||||
avail_sizes = salt.utils.namespaced_function(avail_sizes, globals())
|
||||
script = salt.utils.namespaced_function(script, globals())
|
||||
destroy = salt.utils.namespaced_function(destroy, globals())
|
||||
list_nodes = salt.utils.namespaced_function(list_nodes, globals())
|
||||
list_nodes_full = salt.utils.namespaced_function(list_nodes_full, globals())
|
||||
list_nodes_select = salt.utils.namespaced_function(list_nodes_select, globals())
|
||||
show_instance = salt.utils.namespaced_function(show_instance, globals())
|
||||
|
||||
If necessary, these functions may be replaced by removing the appropriate
|
||||
declaration line, and then adding the function as normal.
|
||||
|
|
@ -183,7 +183,7 @@ imports should be absent from the Salt Cloud module.
|
|||
|
||||
A good example of a non-libcloud driver is the DigitalOcean driver:
|
||||
|
||||
https://github.com/saltstack/salt/tree/develop/salt/cloud/clouds/digital_ocean.py
|
||||
https://github.com/saltstack/salt/tree/develop/salt/cloud/clouds/digitalocean.py
|
||||
|
||||
The ``create()`` Function
|
||||
-------------------------
|
||||
|
|
|
|||
|
|
@ -56,6 +56,24 @@ settings can be placed in the provider or profile:
|
|||
sls_list:
|
||||
- web
|
||||
|
||||
|
||||
When salt cloud creates a new minon, it can automatically add grain information
|
||||
to the minion configuration file identifying the sources originally used
|
||||
to define it.
|
||||
|
||||
The generated grain information will appear similar to:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
grains:
|
||||
salt-cloud:
|
||||
driver: ec2
|
||||
provider: my_ec2:ec2
|
||||
profile: ec2-web
|
||||
|
||||
The generation of the salt-cloud grain can be surpressed by the
|
||||
option ``enable_cloud_grains: 'False'`` in the cloud configuration file.
|
||||
|
||||
Cloud Configuration Syntax
|
||||
==========================
|
||||
|
||||
|
|
@ -426,7 +444,7 @@ under the API Access tab.
|
|||
.. code-block:: yaml
|
||||
|
||||
my-digitalocean-config:
|
||||
driver: digital_ocean
|
||||
driver: digitalocean
|
||||
personal_access_token: xxx
|
||||
location: New York 1
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ under the "SSH Keys" section.
|
|||
# /etc/salt/cloud.providers.d/ directory.
|
||||
|
||||
my-digitalocean-config:
|
||||
driver: digital_ocean
|
||||
driver: digitalocean
|
||||
personal_access_token: xxx
|
||||
ssh_key_file: /path/to/ssh/key/file
|
||||
ssh_key_names: my-key-name,my-key-name-2
|
||||
|
|
@ -63,7 +63,7 @@ command:
|
|||
# salt-cloud --list-locations my-digitalocean-config
|
||||
my-digitalocean-config:
|
||||
----------
|
||||
digital_ocean:
|
||||
digitalocean:
|
||||
----------
|
||||
Amsterdam 1:
|
||||
----------
|
||||
|
|
@ -87,7 +87,7 @@ command:
|
|||
# salt-cloud --list-sizes my-digitalocean-config
|
||||
my-digitalocean-config:
|
||||
----------
|
||||
digital_ocean:
|
||||
digitalocean:
|
||||
----------
|
||||
512MB:
|
||||
----------
|
||||
|
|
@ -117,7 +117,7 @@ command:
|
|||
# salt-cloud --list-images my-digitalocean-config
|
||||
my-digitalocean-config:
|
||||
----------
|
||||
digital_ocean:
|
||||
digitalocean:
|
||||
----------
|
||||
10.1:
|
||||
----------
|
||||
|
|
@ -142,7 +142,7 @@ Profile Specifics:
|
|||
ssh_username
|
||||
------------
|
||||
|
||||
If using a FreeBSD image from Digital Ocean, you'll need to set the ``ssh_username``
|
||||
If using a FreeBSD image from DigitalOcean, you'll need to set the ``ssh_username``
|
||||
setting to ``freebsd`` in your profile configuration.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
|
|
|||
|
|
@ -26,5 +26,5 @@ gathering information about instances on a provider basis:
|
|||
$ salt-cloud -f list_nodes_full linode
|
||||
$ salt-cloud -f list_nodes_select linode
|
||||
|
||||
Another useful reference for viewing salt-cloud functions is the
|
||||
Another useful reference for viewing ``salt-cloud`` functions is the
|
||||
:ref:`Salt Cloud Feature Matrix <salt-cloud-feature-matrix>`.
|
||||
|
|
|
|||
|
|
@ -119,6 +119,7 @@ Cloud Provider Specifics
|
|||
Getting Started With Libvirt <libvirt>
|
||||
Getting Started With Linode <linode>
|
||||
Getting Started With LXC <lxc>
|
||||
Getting Started With OneAndOne <oneandone>
|
||||
Getting Started With OpenNebula <opennebula>
|
||||
Getting Started With OpenStack <openstack>
|
||||
Getting Started With Parallels <parallels>
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ Set up an initial profile at ``/etc/salt/cloud.profiles`` or in the
|
|||
|
||||
.. code-block:: yaml
|
||||
|
||||
joyent_512
|
||||
joyent_512:
|
||||
provider: my-joyent-config
|
||||
size: g4-highcpu-512M
|
||||
image: ubuntu-16.04
|
||||
|
|
|
|||
|
|
@ -8,10 +8,14 @@ libvirt with qemu-kvm.
|
|||
|
||||
http://www.libvirt.org/
|
||||
|
||||
Dependencies
|
||||
Host Dependencies
|
||||
============
|
||||
* libvirt >= 1.2.18 (older might work)
|
||||
|
||||
Salt-Cloud Dependencies
|
||||
============
|
||||
* libvirt-python
|
||||
|
||||
Provider Configuration
|
||||
======================
|
||||
|
||||
|
|
|
|||
|
|
@ -406,4 +406,22 @@ configuration file. For example:
|
|||
- whoami
|
||||
- echo 'hello world!'
|
||||
|
||||
These commands will run in sequence **before** the bootstrap script is executed.
|
||||
These commands will run in sequence **before** the bootstrap script is executed.
|
||||
|
||||
Force Minion Config
|
||||
===================
|
||||
|
||||
.. versionadded:: Oxygen
|
||||
|
||||
The ``force_minion_config`` option requests the bootstrap process to overwrite
|
||||
an existing minion configuration file and public/private key files.
|
||||
Default: False
|
||||
|
||||
This might be important for drivers (such as ``saltify``) which are expected to
|
||||
take over a connection from a former salt master.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
my_saltify_provider:
|
||||
driver: saltify
|
||||
force_minion_config: true
|
||||
|
|
|
|||
146
doc/topics/cloud/oneandone.rst
Normal file
146
doc/topics/cloud/oneandone.rst
Normal file
|
|
@ -0,0 +1,146 @@
|
|||
==========================
|
||||
Getting Started With 1and1
|
||||
==========================
|
||||
|
||||
1&1 is one of the world’s leading Web hosting providers. 1&1 currently offers
|
||||
a wide range of Web hosting products, including email solutions and high-end
|
||||
servers in 10 different countries including Germany, Spain, Great Britain
|
||||
and the United States. From domains to 1&1 MyWebsite to eBusiness solutions
|
||||
like Cloud Hosting and Web servers for complex tasks, 1&1 is well placed to deliver
|
||||
a high quality service to its customers. All 1&1 products are hosted in
|
||||
1&1‘s high-performance, green data centers in the USA and Europe.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
* 1and1 >= 1.2.0
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
* Using the new format, set up the cloud configuration at
|
||||
``/etc/salt/cloud.providers`` or
|
||||
``/etc/salt/cloud.providers.d/oneandone.conf``:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
my-oneandone-config:
|
||||
driver: oneandone
|
||||
|
||||
# Set the location of the salt-master
|
||||
#
|
||||
minion:
|
||||
master: saltmaster.example.com
|
||||
|
||||
# Configure oneandone authentication credentials
|
||||
#
|
||||
api_token: <api_token>
|
||||
ssh_private_key: /path/to/id_rsa
|
||||
ssh_public_key: /path/to/id_rsa.pub
|
||||
|
||||
Authentication
|
||||
==============
|
||||
|
||||
The ``api_key`` is used for API authorization. This token can be obtained
|
||||
from the CloudPanel in the Management section below Users.
|
||||
|
||||
Profiles
|
||||
========
|
||||
|
||||
Here is an example of a profile:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
oneandone_fixed_size:
|
||||
provider: my-oneandone-config
|
||||
description: Small instance size server
|
||||
fixed_instance_size: S
|
||||
appliance_id: 8E3BAA98E3DFD37857810E0288DD8FBA
|
||||
|
||||
oneandone_custom_size:
|
||||
provider: my-oneandone-config
|
||||
description: Custom size server
|
||||
vcore: 2
|
||||
cores_per_processor: 2
|
||||
ram: 8
|
||||
appliance_id: 8E3BAA98E3DFD37857810E0288DD8FBA
|
||||
hdds:
|
||||
-
|
||||
is_main: true
|
||||
size: 20
|
||||
-
|
||||
is_main: false
|
||||
size: 20
|
||||
|
||||
The following list explains some of the important properties.
|
||||
|
||||
fixed_instance_size_id
|
||||
When creating a server, either ``fixed_instance_size_id`` or custom hardware params
|
||||
containing ``vcore``, ``cores_per_processor``, ``ram``, and ``hdds`` must be provided.
|
||||
Can be one of the IDs listed among the output of the following command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt-cloud --list-sizes oneandone
|
||||
|
||||
vcore
|
||||
Total amount of processors.
|
||||
|
||||
cores_per_processor
|
||||
Number of cores per processor.
|
||||
|
||||
ram
|
||||
RAM memory size in GB.
|
||||
|
||||
hdds
|
||||
Hard disks.
|
||||
|
||||
appliance_id
|
||||
ID of the image that will be installed on server.
|
||||
Can be one of the IDs listed in the output of the following command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt-cloud --list-images oneandone
|
||||
|
||||
datacenter_id
|
||||
ID of the datacenter where the server will be created.
|
||||
Can be one of the IDs listed in the output of the following command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt-cloud --list-locations oneandone
|
||||
|
||||
description
|
||||
Description of the server.
|
||||
|
||||
password
|
||||
Password of the server. Password must contain more than 8 characters
|
||||
using uppercase letters, numbers and other special symbols.
|
||||
|
||||
power_on
|
||||
Power on server after creation. Default is set to true.
|
||||
|
||||
firewall_policy_id
|
||||
Firewall policy ID. If it is not provided, the server will assign
|
||||
the best firewall policy, creating a new one if necessary. If the parameter
|
||||
is sent with a 0 value, the server will be created with all ports blocked.
|
||||
|
||||
ip_id
|
||||
IP address ID.
|
||||
|
||||
load_balancer_id
|
||||
Load balancer ID.
|
||||
|
||||
monitoring_policy_id
|
||||
Monitoring policy ID.
|
||||
|
||||
deploy
|
||||
Set to False if Salt should not be installed on the node.
|
||||
|
||||
wait_for_timeout
|
||||
The timeout to wait in seconds for provisioning resources such as servers.
|
||||
The default wait_for_timeout is 15 minutes.
|
||||
|
||||
For more information concerning cloud profiles, see :ref:`here
|
||||
<salt-cloud-profiles>`.
|
||||
|
|
@ -16,7 +16,7 @@ The Saltify driver has no external dependencies.
|
|||
Configuration
|
||||
=============
|
||||
|
||||
Because the Saltify driver does not use an actual cloud provider host, it has a
|
||||
Because the Saltify driver does not use an actual cloud provider host, it can have a
|
||||
simple provider configuration. The only thing that is required to be set is the
|
||||
driver name, and any other potentially useful information, like the location of
|
||||
the salt-master:
|
||||
|
|
@ -31,6 +31,12 @@ the salt-master:
|
|||
master: 111.222.333.444
|
||||
provider: saltify
|
||||
|
||||
However, if you wish to use the more advanced capabilities of salt-cloud, such as
|
||||
rebooting, listing, and disconnecting machines, then the salt master must fill
|
||||
the role usually performed by a vendor's cloud management system. In order to do
|
||||
that, you must configure your salt master as a salt-api server, and supply credentials
|
||||
to use it. (See ``salt-api setup`` below.)
|
||||
|
||||
|
||||
Profiles
|
||||
========
|
||||
|
|
@ -72,6 +78,30 @@ to it can be verified with Salt:
|
|||
salt my-machine test.ping
|
||||
|
||||
|
||||
Destroy Options
|
||||
---------------
|
||||
|
||||
For obvious reasons, the ``destroy`` action does not actually vaporize hardware.
|
||||
If the salt master is connected using salt-api, it can tear down parts of
|
||||
the client machines. It will remove the client's key from the salt master,
|
||||
and will attempt the following options:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- remove_config_on_destroy: true
|
||||
# default: true
|
||||
# Deactivate salt-minion on reboot and
|
||||
# delete the minion config and key files from its ``/etc/salt`` directory,
|
||||
# NOTE: If deactivation is unsuccessful (older Ubuntu machines) then when
|
||||
# salt-minion restarts it will automatically create a new, unwanted, set
|
||||
# of key files. The ``force_minion_config`` option must be used in that case.
|
||||
|
||||
- shutdown_on_destroy: false
|
||||
# default: false
|
||||
# send a ``shutdown`` command to the client.
|
||||
|
||||
.. versionadded:: Oxygen
|
||||
|
||||
Using Map Files
|
||||
---------------
|
||||
The settings explained in the section above may also be set in a map file. An
|
||||
|
|
@ -135,3 +165,67 @@ Return values:
|
|||
- ``True``: Credential verification succeeded
|
||||
- ``False``: Credential verification succeeded
|
||||
- ``None``: Credential verification was not attempted.
|
||||
|
||||
Provisioning salt-api
|
||||
=====================
|
||||
|
||||
In order to query or control minions it created, saltify needs to send commands
|
||||
to the salt master. It does that using the network interface to salt-api.
|
||||
|
||||
The salt-api is not enabled by default. The following example will provide a
|
||||
simple installation.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# file /etc/salt/cloud.profiles.d/my_saltify_profiles.conf
|
||||
hw_41: # a theoretical example hardware machine
|
||||
ssh_host: 10.100.9.41 # the hard address of your target
|
||||
ssh_username: vagrant # a user name which has passwordless sudo
|
||||
password: vagrant # on your target machine
|
||||
provider: my_saltify_provider
|
||||
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# file /etc/salt/cloud.providers.d/saltify_provider.conf
|
||||
my_saltify_provider:
|
||||
driver: saltify
|
||||
eauth: pam
|
||||
username: vagrant # supply some sudo-group-member's name
|
||||
password: vagrant # and password on the salt master
|
||||
minion:
|
||||
master: 10.100.9.5 # the hard address of the master
|
||||
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# file /etc/salt/master.d/auth.conf
|
||||
# using salt-api ... members of the 'sudo' group can do anything ...
|
||||
external_auth:
|
||||
pam:
|
||||
sudo%:
|
||||
- .*
|
||||
- '@wheel'
|
||||
- '@runner'
|
||||
- '@jobs'
|
||||
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# file /etc/salt/master.d/api.conf
|
||||
# see https://docs.saltstack.com/en/latest/ref/netapi/all/salt.netapi.rest_cherrypy.html
|
||||
rest_cherrypy:
|
||||
host: localhost
|
||||
port: 8000
|
||||
ssl_crt: /etc/pki/tls/certs/localhost.crt
|
||||
ssl_key: /etc/pki/tls/certs/localhost.key
|
||||
thread_pool: 30
|
||||
socket_queue_size: 10
|
||||
|
||||
|
||||
Start your target machine as a Salt minion named "node41" by:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo salt-cloud -p hw_41 node41
|
||||
|
||||
|
|
|
|||
|
|
@ -260,6 +260,21 @@ The Salt development team will back-port bug fixes made to ``develop`` to the
|
|||
current release branch if the contributor cannot create the pull request
|
||||
against that branch.
|
||||
|
||||
Release Branches
|
||||
----------------
|
||||
|
||||
For each release, a branch will be created when the SaltStack release team is
|
||||
ready to tag. The release branch is created from the parent branch and will be
|
||||
the same name as the tag minus the ``v``. For example, the ``2017.7.1`` release
|
||||
branch was created from the ``2017.7`` parent branch and the ``v2017.7.1``
|
||||
release was tagged at the ``HEAD`` of the ``2017.7.1`` branch. This branching
|
||||
strategy will allow for more stability when there is a need for a re-tag during
|
||||
the testing phase of the release process.
|
||||
|
||||
Once the release branch is created, the fixes required for a given release, as
|
||||
determined by the SaltStack release team, will be added to this branch. All
|
||||
commits in this branch will be merged forward into the parent branch as well.
|
||||
|
||||
Keeping Salt Forks in Sync
|
||||
==========================
|
||||
|
||||
|
|
|
|||
|
|
@ -18,10 +18,10 @@ on the significance and complexity of the changes required by the user.
|
|||
|
||||
Salt feature releases are based on the Periodic Table. Any new features going
|
||||
into the develop branch will be named after the next element in the Periodic
|
||||
Table. For example, Beryllium was the feature release name of the develop branch
|
||||
before the 2015.8 branch was tagged. At that point in time, any new features going
|
||||
into the develop branch after 2015.8 was branched were part of the Boron feature
|
||||
release.
|
||||
Table. For example, Beryllium was the feature release name of the develop
|
||||
branch before the 2015.8 branch was tagged. At that point in time, any new
|
||||
features going into the develop branch after 2015.8 was branched were part of
|
||||
the Boron feature release.
|
||||
|
||||
A deprecation warning should be in place for at least two major releases before
|
||||
the deprecated code and its accompanying deprecation warning are removed. More
|
||||
|
|
@ -29,14 +29,14 @@ time should be given for more complex changes. For example, if the current
|
|||
release under development is ``Sodium``, the deprecated code and associated
|
||||
warnings should remain in place and warn for at least ``Aluminum``.
|
||||
|
||||
To help in this deprecation task, salt provides :func:`salt.utils.warn_until
|
||||
<salt.utils.warn_until>`. The idea behind this helper function is to show the
|
||||
deprecation warning to the user until salt reaches the provided version. Once
|
||||
that provided version is equaled :func:`salt.utils.warn_until
|
||||
<salt.utils.warn_until>` will raise a :py:exc:`RuntimeError` making salt stop
|
||||
its execution. This stoppage is unpleasant and will remind the developer that
|
||||
the deprecation limit has been reached and that the code can then be safely
|
||||
removed.
|
||||
To help in this deprecation task, salt provides
|
||||
:func:`salt.utils.versions.warn_until <salt.utils.versions.warn_until>`. The
|
||||
idea behind this helper function is to show the deprecation warning to the user
|
||||
until salt reaches the provided version. Once that provided version is equaled
|
||||
:func:`salt.utils.versions.warn_until <salt.utils.versions.warn_until>` will
|
||||
raise a :py:exc:`RuntimeError` making salt stop its execution. This stoppage is
|
||||
unpleasant and will remind the developer that the deprecation limit has been
|
||||
reached and that the code can then be safely removed.
|
||||
|
||||
Consider the following example:
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ Consider the following example:
|
|||
|
||||
def some_function(bar=False, foo=None):
|
||||
if foo is not None:
|
||||
salt.utils.warn_until(
|
||||
salt.utils.versions.warn_until(
|
||||
'Aluminum',
|
||||
'The \'foo\' argument has been deprecated and its '
|
||||
'functionality removed, as such, its usage is no longer '
|
||||
|
|
|
|||
|
|
@ -219,7 +219,7 @@ the default cloud provider configuration file for DigitalOcean looks like this:
|
|||
.. code-block:: yaml
|
||||
|
||||
digitalocean-config:
|
||||
driver: digital_ocean
|
||||
driver: digitalocean
|
||||
client_key: ''
|
||||
api_key: ''
|
||||
location: New York 1
|
||||
|
|
@ -230,7 +230,7 @@ must be provided:
|
|||
.. code-block:: yaml
|
||||
|
||||
digitalocean-config:
|
||||
driver: digital_ocean
|
||||
driver: digitalocean
|
||||
client_key: wFGEwgregeqw3435gDger
|
||||
api_key: GDE43t43REGTrkilg43934t34qT43t4dgegerGEgg
|
||||
location: New York 1
|
||||
|
|
|
|||
|
|
@ -541,7 +541,7 @@ provider configuration file in the integration test file directory located at
|
|||
``tests/integration/files/conf/cloud.*.d/``.
|
||||
|
||||
The following is an example of the default profile configuration file for Digital
|
||||
Ocean, located at: ``tests/integration/files/conf/cloud.profiles.d/digital_ocean.conf``:
|
||||
Ocean, located at: ``tests/integration/files/conf/cloud.profiles.d/digitalocean.conf``:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -557,12 +557,12 @@ be provided by the user by editing the provider configuration file before runnin
|
|||
tests.
|
||||
|
||||
The following is an example of the default provider configuration file for Digital
|
||||
Ocean, located at: ``tests/integration/files/conf/cloud.providers.d/digital_ocean.conf``:
|
||||
Ocean, located at: ``tests/integration/files/conf/cloud.providers.d/digitalocean.conf``:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
digitalocean-config:
|
||||
driver: digital_ocean
|
||||
driver: digitalocean
|
||||
client_key: ''
|
||||
api_key: ''
|
||||
location: New York 1
|
||||
|
|
|
|||
|
|
@ -319,7 +319,7 @@ function into ``__salt__`` that's actually a MagicMock instance.
|
|||
|
||||
def show_patch(self):
|
||||
with patch.dict(my_module.__salt__,
|
||||
{'function.to_replace': MagicMock()}:
|
||||
{'function.to_replace': MagicMock()}):
|
||||
# From this scope, carry on with testing, with a modified __salt__!
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -93,6 +93,26 @@ By user, by minion:
|
|||
<minion compound target>:
|
||||
- <regex to match function>
|
||||
|
||||
By user, by runner/wheel:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
external_auth:
|
||||
<eauth backend>:
|
||||
<user or group%>:
|
||||
<@runner or @wheel>:
|
||||
- <regex to match function>
|
||||
|
||||
By user, by runner+wheel module:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
external_auth:
|
||||
<eauth backend>:
|
||||
<user or group%>:
|
||||
<@module_name>:
|
||||
- <regex to match function without module_name>
|
||||
|
||||
Groups
|
||||
------
|
||||
|
||||
|
|
@ -127,6 +147,14 @@ Positional arguments or keyword arguments to functions can also be whitelisted.
|
|||
kwargs:
|
||||
'kwa': 'kwa.*'
|
||||
'kwb': 'kwb'
|
||||
- '@runner':
|
||||
- 'runner_mod.*':
|
||||
args:
|
||||
- 'a.*'
|
||||
- 'b.*'
|
||||
kwargs:
|
||||
'kwa': 'kwa.*'
|
||||
'kwb': 'kwb'
|
||||
|
||||
The rules:
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,12 @@ Salt engines are configured under an ``engines`` top-level section in your Salt
|
|||
port: 5959
|
||||
proto: tcp
|
||||
|
||||
Salt engines must be in the Salt path, or you can add the ``engines_dirs`` option in your Salt master configuration with a list of directories under which Salt attempts to find Salt engines.
|
||||
Salt engines must be in the Salt path, or you can add the ``engines_dirs`` option in your Salt master configuration with a list of directories under which Salt attempts to find Salt engines. This option should be formatted as a list of directories to search, such as:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
engines_dirs:
|
||||
- /home/bob/engines
|
||||
|
||||
Writing an Engine
|
||||
=================
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Installation from official Debian and Raspbian repositories is described
|
|||
Installation from the Official SaltStack Repository
|
||||
===================================================
|
||||
|
||||
Packages for Debian 8 (Jessie) and Debian 7 (Wheezy) are available in the
|
||||
Packages for Debian 9 (Stretch) and Debian 8 (Jessie) are available in the
|
||||
Official SaltStack repository.
|
||||
|
||||
Instructions are at https://repo.saltstack.com/#debian.
|
||||
|
|
|
|||
154
doc/topics/installation/eos.rst
Normal file
154
doc/topics/installation/eos.rst
Normal file
|
|
@ -0,0 +1,154 @@
|
|||
=========================================
|
||||
Arista EOS Salt minion installation guide
|
||||
=========================================
|
||||
|
||||
The Salt minion for Arista EOS is distributed as a SWIX extension and can be installed directly on the switch. The EOS network operating system is based on old Fedora distributions and the installation of the ``salt-minion`` requires backports. This SWIX extension contains the necessary backports, together with the Salt basecode.
|
||||
|
||||
.. note::
|
||||
|
||||
This SWIX extension has been tested on Arista DCS-7280SE-68-R, running EOS 4.17.5M and vEOS 4.18.3F.
|
||||
|
||||
Important Notes
|
||||
===============
|
||||
|
||||
This package is in beta, make sure to test it carefully before running it in production.
|
||||
|
||||
If confirmed working correctly, please report and add a note on this page with the platform model and EOS version.
|
||||
|
||||
If you want to uninstall this package, please refer to the uninstalling_ section.
|
||||
|
||||
Installation from the Official SaltStack Repository
|
||||
===================================================
|
||||
|
||||
Download the swix package and save it to flash.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
veos#copy https://salt-eos.netops.life/salt-eos-latest.swix flash:
|
||||
veos#copy https://salt-eos.netops.life/startup.sh flash:
|
||||
|
||||
Install the Extension
|
||||
=====================
|
||||
|
||||
Copy the Salt package to extension
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
veos#copy flash:salt-eos-latest.swix extension:
|
||||
|
||||
Install the SWIX
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
veos#extension salt-eos-latest.swix force
|
||||
|
||||
Verify the installation
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
veos#show extensions | include salt-eos
|
||||
salt-eos-2017-07-19.swix 1.0.11/1.fc25 A, F 27
|
||||
|
||||
Change the Salt master IP address or FQDN, by edit the variable (SALT_MASTER)
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
veos#bash vi /mnt/flash/startup.sh
|
||||
|
||||
Make sure you enable the eAPI with unix-socket
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
veos(config)#management api http-commands
|
||||
protocol unix-socket
|
||||
no shutdown
|
||||
|
||||
Post-installation tasks
|
||||
=======================
|
||||
|
||||
Generate Keys and host record and start Salt minion
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
veos#bash
|
||||
#sudo /mnt/flash/startup.sh
|
||||
|
||||
``salt-minion`` should be running
|
||||
|
||||
Copy the installed extensions to boot-extensions
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
veos#copy installed-extensions boot-extensions
|
||||
|
||||
Apply event-handler to let EOS start salt-minion during boot-up
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
veos(config)#event-handler boot-up-script
|
||||
trigger on-boot
|
||||
action bash sudo /mnt/flash/startup.sh
|
||||
|
||||
For more specific installation details of the ``salt-minion``, please refer to :ref:`Configuring Salt<configuring-salt>`.
|
||||
|
||||
.. _uninstalling:
|
||||
|
||||
Uninstalling
|
||||
============
|
||||
|
||||
If you decide to uninstall this package, the following steps are recommended for safety:
|
||||
|
||||
1. Remove the extension from boot-extensions
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
veos#bash rm /mnt/flash/boot-extensions
|
||||
|
||||
2. Remove the extension from extensions folder
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
veos#bash rm /mnt/flash/.extensions/salt-eos-latest.swix
|
||||
|
||||
2. Remove boot-up script
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
veos(config)#no event-handler boot-up-script
|
||||
|
||||
Additional Information
|
||||
======================
|
||||
|
||||
This SWIX extension contains the following RPM packages:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
libsodium-1.0.11-1.fc25.i686.rpm
|
||||
libstdc++-6.2.1-2.fc25.i686.rpm
|
||||
openpgm-5.2.122-6.fc24.i686.rpm
|
||||
python-Jinja2-2.8-0.i686.rpm
|
||||
python-PyYAML-3.12-0.i686.rpm
|
||||
python-babel-0.9.6-5.fc18.noarch.rpm
|
||||
python-backports-1.0-3.fc18.i686.rpm
|
||||
python-backports-ssl_match_hostname-3.4.0.2-1.fc18.noarch.rpm
|
||||
python-backports_abc-0.5-0.i686.rpm
|
||||
python-certifi-2016.9.26-0.i686.rpm
|
||||
python-chardet-2.0.1-5.fc18.noarch.rpm
|
||||
python-crypto-1.4.1-1.noarch.rpm
|
||||
python-crypto-2.6.1-1.fc18.i686.rpm
|
||||
python-futures-3.1.1-1.noarch.rpm
|
||||
python-jtextfsm-0.3.1-0.noarch.rpm
|
||||
python-kitchen-1.1.1-2.fc18.noarch.rpm
|
||||
python-markupsafe-0.18-1.fc18.i686.rpm
|
||||
python-msgpack-python-0.4.8-0.i686.rpm
|
||||
python-napalm-base-0.24.3-1.noarch.rpm
|
||||
python-napalm-eos-0.6.0-1.noarch.rpm
|
||||
python-netaddr-0.7.18-0.noarch.rpm
|
||||
python-pyeapi-0.7.0-0.noarch.rpm
|
||||
python-salt-2017.7.0_1414_g2fb986f-1.noarch.rpm
|
||||
python-singledispatch-3.4.0.3-0.i686.rpm
|
||||
python-six-1.10.0-0.i686.rpm
|
||||
python-tornado-4.4.2-0.i686.rpm
|
||||
python-urllib3-1.5-7.fc18.noarch.rpm
|
||||
python2-zmq-15.3.0-2.fc25.i686.rpm
|
||||
zeromq-4.1.4-5.fc25.i686.rpm
|
||||
|
|
@ -46,6 +46,7 @@ These guides go into detail how to install Salt on a given platform.
|
|||
|
||||
arch
|
||||
debian
|
||||
eos
|
||||
fedora
|
||||
freebsd
|
||||
gentoo
|
||||
|
|
|
|||
|
|
@ -828,12 +828,14 @@ Returns:
|
|||
08.03.2017 17:00
|
||||
|
||||
|
||||
.. jinja_ref:: str_to_num
|
||||
.. jinja_ref:: to_num
|
||||
|
||||
``str_to_num``
|
||||
--------------
|
||||
``to_num``
|
||||
----------
|
||||
|
||||
.. versionadded:: 2017.7.0
|
||||
.. versionadded:: Oxygen
|
||||
Renamed from ``str_to_num`` to ``to_num``.
|
||||
|
||||
Converts a string to its numerical value.
|
||||
|
||||
|
|
@ -841,7 +843,7 @@ Example:
|
|||
|
||||
.. code-block:: jinja
|
||||
|
||||
{{ '5' | str_to_num }}
|
||||
{{ '5' | to_num }}
|
||||
|
||||
Returns:
|
||||
|
||||
|
|
@ -917,10 +919,10 @@ Returns:
|
|||
{'a': 'b'}
|
||||
|
||||
|
||||
.. jinja_ref:: rand_str
|
||||
.. jinja_ref:: random_hash
|
||||
|
||||
``rand_str``
|
||||
------------
|
||||
``random_hash``
|
||||
---------------
|
||||
|
||||
.. versionadded:: 2017.7.0
|
||||
.. versionadded:: Oxygen
|
||||
|
|
@ -937,8 +939,8 @@ Example:
|
|||
.. code-block:: jinja
|
||||
|
||||
{% set num_range = 99999999 %}
|
||||
{{ num_range | rand_str }}
|
||||
{{ num_range | rand_str('sha512') }}
|
||||
{{ num_range | random_hash }}
|
||||
{{ num_range | random_hash('sha512') }}
|
||||
|
||||
Returns:
|
||||
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ they are being loaded for the correct proxytype, example below:
|
|||
Only work on proxy
|
||||
'''
|
||||
try:
|
||||
if salt.utils.is_proxy() and \
|
||||
if salt.utils.platform.is_proxy() and \
|
||||
__opts__['proxy']['proxytype'] == 'ssh_sample':
|
||||
return __virtualname__
|
||||
except KeyError:
|
||||
|
|
@ -156,20 +156,23 @@ will need to be restarted to pick up any changes. A corresponding utility funct
|
|||
``saltutil.sync_proxymodules``, has been added to sync these modules to minions.
|
||||
|
||||
In addition, a salt.utils helper function called `is_proxy()` was added to make
|
||||
it easier to tell when the running minion is a proxy minion.
|
||||
it easier to tell when the running minion is a proxy minion. **NOTE: This
|
||||
function was renamed to salt.utils.platform.is_proxy() for the Oxygen release**
|
||||
|
||||
New in 2015.8
|
||||
-------------
|
||||
|
||||
Starting with the 2015.8 release of Salt, proxy processes are no longer forked off from a controlling minion.
|
||||
Instead, they have their own script ``salt-proxy`` which takes mostly the same arguments that the
|
||||
standard Salt minion does with the addition of ``--proxyid``. This is the id that the salt-proxy will
|
||||
use to identify itself to the master. Proxy configurations are still best kept in Pillar and their format
|
||||
has not changed.
|
||||
Starting with the 2015.8 release of Salt, proxy processes are no longer forked
|
||||
off from a controlling minion. Instead, they have their own script
|
||||
``salt-proxy`` which takes mostly the same arguments that the standard Salt
|
||||
minion does with the addition of ``--proxyid``. This is the id that the
|
||||
salt-proxy will use to identify itself to the master. Proxy configurations are
|
||||
still best kept in Pillar and their format has not changed.
|
||||
|
||||
This change allows for better process control and logging. Proxy processes can now be listed with standard
|
||||
process management utilities (``ps`` from the command line). Also, a full Salt minion is no longer
|
||||
required (though it is still strongly recommended) on machines hosting proxies.
|
||||
This change allows for better process control and logging. Proxy processes can
|
||||
now be listed with standard process management utilities (``ps`` from the
|
||||
command line). Also, a full Salt minion is no longer required (though it is
|
||||
still strongly recommended) on machines hosting proxies.
|
||||
|
||||
|
||||
Getting Started
|
||||
|
|
@ -619,9 +622,10 @@ in the proxymodule itself. This might be useful if a proxymodule author wants t
|
|||
all the code for the proxy interface in the same place instead of splitting it between
|
||||
the proxy and grains directories.
|
||||
|
||||
This function will only be called automatically if the configuration variable ``proxy_merge_grains_in_module``
|
||||
is set to True in the proxy configuration file (default ``/etc/salt/proxy``). This
|
||||
variable defaults to ``True`` in the release code-named *2017.7.0*.
|
||||
This function will only be called automatically if the configuration variable
|
||||
``proxy_merge_grains_in_module`` is set to True in the proxy configuration file
|
||||
(default ``/etc/salt/proxy``). This variable defaults to ``True`` in the
|
||||
release code-named *2017.7.0*.
|
||||
|
||||
|
||||
.. code: python::
|
||||
|
|
@ -640,7 +644,7 @@ variable defaults to ``True`` in the release code-named *2017.7.0*.
|
|||
|
||||
def __virtual__():
|
||||
try:
|
||||
if salt.utils.is_proxy() and __opts__['proxy']['proxytype'] == 'rest_sample':
|
||||
if salt.utils.platform.is_proxy() and __opts__['proxy']['proxytype'] == 'rest_sample':
|
||||
return __virtualname__
|
||||
except KeyError:
|
||||
pass
|
||||
|
|
@ -708,7 +712,7 @@ Example from ``salt/grains/rest_sample.py``:
|
|||
|
||||
def __virtual__():
|
||||
try:
|
||||
if salt.utils.is_proxy() and __opts__['proxy']['proxytype'] == 'rest_sample':
|
||||
if salt.utils.platform.is_proxy() and __opts__['proxy']['proxytype'] == 'rest_sample':
|
||||
return __virtualname__
|
||||
except KeyError:
|
||||
pass
|
||||
|
|
|
|||
|
|
@ -27,9 +27,9 @@ event bus is an open system used for sending information notifying Salt and
|
|||
other systems about operations.
|
||||
|
||||
The event system fires events with a very specific criteria. Every event has a
|
||||
:strong:`tag`. Event tags allow for fast top level filtering of events. In
|
||||
addition to the tag, each event has a data structure. This data structure is a
|
||||
dict, which contains information about the event.
|
||||
**tag**. Event tags allow for fast top-level filtering of events. In addition
|
||||
to the tag, each event has a data structure. This data structure is a
|
||||
dictionary, which contains information about the event.
|
||||
|
||||
.. _reactor-mapping-events:
|
||||
|
||||
|
|
@ -65,15 +65,12 @@ and each event tag has a list of reactor SLS files to be run.
|
|||
the :ref:`querystring syntax <querystring-syntax>` (e.g.
|
||||
``salt://reactor/mycustom.sls?saltenv=reactor``).
|
||||
|
||||
Reactor sls files are similar to state and pillar sls files. They are
|
||||
by default yaml + Jinja templates and are passed familiar context variables.
|
||||
Reactor SLS files are similar to State and Pillar SLS files. They are by
|
||||
default YAML + Jinja templates and are passed familiar context variables.
|
||||
Click :ref:`here <reactor-jinja-context>` for more detailed information on the
|
||||
variables availble in Jinja templating.
|
||||
|
||||
They differ because of the addition of the ``tag`` and ``data`` variables.
|
||||
|
||||
- The ``tag`` variable is just the tag in the fired event.
|
||||
- The ``data`` variable is the event's data dict.
|
||||
|
||||
Here is a simple reactor sls:
|
||||
Here is the SLS for a simple reaction:
|
||||
|
||||
.. code-block:: jinja
|
||||
|
||||
|
|
@ -90,71 +87,278 @@ data structure and compiler used for the state system is used for the reactor
|
|||
system. The only difference is that the data is matched up to the salt command
|
||||
API and the runner system. In this example, a command is published to the
|
||||
``mysql1`` minion with a function of :py:func:`state.apply
|
||||
<salt.modules.state.apply_>`. Similarly, a runner can be called:
|
||||
<salt.modules.state.apply_>`, which performs a :ref:`highstate
|
||||
<running-highstate>`. Similarly, a runner can be called:
|
||||
|
||||
.. code-block:: jinja
|
||||
|
||||
{% if data['data']['custom_var'] == 'runit' %}
|
||||
call_runit_orch:
|
||||
runner.state.orchestrate:
|
||||
- mods: _orch.runit
|
||||
- args:
|
||||
- mods: orchestrate.runit
|
||||
{% endif %}
|
||||
|
||||
This example will execute the state.orchestrate runner and intiate an execution
|
||||
of the runit orchestrator located at ``/srv/salt/_orch/runit.sls``. Using
|
||||
``_orch/`` is any arbitrary path but it is recommended to avoid using "orchestrate"
|
||||
as this is most likely to cause confusion.
|
||||
of the ``runit`` orchestrator located at ``/srv/salt/orchestrate/runit.sls``.
|
||||
|
||||
Writing SLS Files
|
||||
-----------------
|
||||
Types of Reactions
|
||||
==================
|
||||
|
||||
Reactor SLS files are stored in the same location as State SLS files. This means
|
||||
that both ``file_roots`` and ``gitfs_remotes`` impact what SLS files are
|
||||
available to the reactor and orchestrator.
|
||||
============================== ==================================================================================
|
||||
Name Description
|
||||
============================== ==================================================================================
|
||||
:ref:`local <reactor-local>` Runs a :ref:`remote-execution function <all-salt.modules>` on targeted minions
|
||||
:ref:`runner <reactor-runner>` Executes a :ref:`runner function <all-salt.runners>`
|
||||
:ref:`wheel <reactor-wheel>` Executes a :ref:`wheel function <all-salt.wheel>` on the master
|
||||
:ref:`caller <reactor-caller>` Runs a :ref:`remote-execution function <all-salt.modules>` on a masterless minion
|
||||
============================== ==================================================================================
|
||||
|
||||
It is recommended to keep reactor and orchestrator SLS files in their own uniquely
|
||||
named subdirectories such as ``_orch/``, ``orch/``, ``_orchestrate/``, ``react/``,
|
||||
``_reactor/``, etc. Keeping a unique name helps prevent confusion when trying to
|
||||
read through this a few years down the road.
|
||||
.. note::
|
||||
The ``local`` and ``caller`` reaction types will be renamed for the Oxygen
|
||||
release. These reaction types were named after Salt's internal client
|
||||
interfaces, and are not intuitively named. Both ``local`` and ``caller``
|
||||
will continue to work in Reactor SLS files, but for the Oxygen release the
|
||||
documentation will be updated to reflect the new preferred naming.
|
||||
|
||||
The Goal of Writing Reactor SLS Files
|
||||
=====================================
|
||||
Where to Put Reactor SLS Files
|
||||
==============================
|
||||
|
||||
Reactor SLS files share the familiar syntax from Salt States but there are
|
||||
important differences. The goal of a Reactor file is to process a Salt event as
|
||||
quickly as possible and then to optionally start a **new** process in response.
|
||||
Reactor SLS files can come both from files local to the master, and from any of
|
||||
backends enabled via the :conf_master:`fileserver_backend` config option. Files
|
||||
placed in the Salt fileserver can be referenced using a ``salt://`` URL, just
|
||||
like they can in State SLS files.
|
||||
|
||||
1. The Salt Reactor watches Salt's event bus for new events.
|
||||
2. The event tag is matched against the list of event tags under the
|
||||
``reactor`` section in the Salt Master config.
|
||||
3. The SLS files for any matches are Rendered into a data structure that
|
||||
represents one or more function calls.
|
||||
4. That data structure is given to a pool of worker threads for execution.
|
||||
It is recommended to place reactor and orchestrator SLS files in their own
|
||||
uniquely-named subdirectories such as ``orch/``, ``orchestrate/``, ``react/``,
|
||||
``reactor/``, etc., to keep them organized.
|
||||
|
||||
.. _reactor-sls:
|
||||
|
||||
Writing Reactor SLS
|
||||
===================
|
||||
|
||||
The different reaction types were developed separately and have historically
|
||||
had different methods for passing arguments. For the 2017.7.2 release a new,
|
||||
unified configuration schema has been introduced, which applies to all reaction
|
||||
types.
|
||||
|
||||
The old config schema will continue to be supported, and there is no plan to
|
||||
deprecate it at this time.
|
||||
|
||||
.. _reactor-local:
|
||||
|
||||
Local Reactions
|
||||
---------------
|
||||
|
||||
A ``local`` reaction runs a :ref:`remote-execution function <all-salt.modules>`
|
||||
on the targeted minions.
|
||||
|
||||
The old config schema required the positional and keyword arguments to be
|
||||
manually separated by the user under ``arg`` and ``kwarg`` parameters. However,
|
||||
this is not very user-friendly, as it forces the user to distinguish which type
|
||||
of argument is which, and make sure that positional arguments are ordered
|
||||
properly. Therefore, the new config schema is recommended if the master is
|
||||
running a supported release.
|
||||
|
||||
The below two examples are equivalent:
|
||||
|
||||
+---------------------------------+-----------------------------+
|
||||
| Supported in 2017.7.2 and later | Supported in all releases |
|
||||
+=================================+=============================+
|
||||
| :: | :: |
|
||||
| | |
|
||||
| install_zsh: | install_zsh: |
|
||||
| local.state.single: | local.state.single: |
|
||||
| - tgt: 'kernel:Linux' | - tgt: 'kernel:Linux' |
|
||||
| - tgt_type: grain | - tgt_type: grain |
|
||||
| - args: | - arg: |
|
||||
| - fun: pkg.installed | - pkg.installed |
|
||||
| - name: zsh | - zsh |
|
||||
| - fromrepo: updates | - kwarg: |
|
||||
| | fromrepo: updates |
|
||||
+---------------------------------+-----------------------------+
|
||||
|
||||
This reaction would be equvalent to running the following Salt command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt -G 'kernel:Linux' state.single pkg.installed name=zsh fromrepo=updates
|
||||
|
||||
.. note::
|
||||
Any other parameters in the :py:meth:`LocalClient().cmd_async()
|
||||
<salt.client.LocalClient.cmd_async>` method can be passed at the same
|
||||
indentation level as ``tgt``.
|
||||
|
||||
.. note::
|
||||
``tgt_type`` is only required when the target expression defined in ``tgt``
|
||||
uses a :ref:`target type <targeting>` other than a minion ID glob.
|
||||
|
||||
The ``tgt_type`` argument was named ``expr_form`` in releases prior to
|
||||
2017.7.0.
|
||||
|
||||
.. _reactor-runner:
|
||||
|
||||
Runner Reactions
|
||||
----------------
|
||||
|
||||
Runner reactions execute :ref:`runner functions <all-salt.runners>` locally on
|
||||
the master.
|
||||
|
||||
The old config schema called for passing arguments to the reaction directly
|
||||
under the name of the runner function. However, this can cause unpredictable
|
||||
interactions with the Reactor system's internal arguments. It is also possible
|
||||
to pass positional and keyword arguments under ``arg`` and ``kwarg`` like above
|
||||
in :ref:`local reactions <reactor-local>`, but as noted above this is not very
|
||||
user-friendly. Therefore, the new config schema is recommended if the master
|
||||
is running a supported release.
|
||||
|
||||
The below two examples are equivalent:
|
||||
|
||||
+-------------------------------------------------+-------------------------------------------------+
|
||||
| Supported in 2017.7.2 and later | Supported in all releases |
|
||||
+=================================================+=================================================+
|
||||
| :: | :: |
|
||||
| | |
|
||||
| deploy_app: | deploy_app: |
|
||||
| runner.state.orchestrate: | runner.state.orchestrate: |
|
||||
| - args: | - mods: orchestrate.deploy_app |
|
||||
| - mods: orchestrate.deploy_app | - kwarg: |
|
||||
| - pillar: | pillar: |
|
||||
| event_tag: {{ tag }} | event_tag: {{ tag }} |
|
||||
| event_data: {{ data['data']|json }} | event_data: {{ data['data']|json }} |
|
||||
+-------------------------------------------------+-------------------------------------------------+
|
||||
|
||||
Assuming that the event tag is ``foo``, and the data passed to the event is
|
||||
``{'bar': 'baz'}``, then this reaction is equvalent to running the following
|
||||
Salt command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt-run state.orchestrate mods=orchestrate.deploy_app pillar='{"event_tag": "foo", "event_data": {"bar": "baz"}}'
|
||||
|
||||
.. _reactor-wheel:
|
||||
|
||||
Wheel Reactions
|
||||
---------------
|
||||
|
||||
Wheel reactions run :ref:`wheel functions <all-salt.wheel>` locally on the
|
||||
master.
|
||||
|
||||
Like :ref:`runner reactions <reactor-runner>`, the old config schema called for
|
||||
wheel reactions to have arguments passed directly under the name of the
|
||||
:ref:`wheel function <all-salt.wheel>` (or in ``arg`` or ``kwarg`` parameters).
|
||||
|
||||
The below two examples are equivalent:
|
||||
|
||||
+-----------------------------------+---------------------------------+
|
||||
| Supported in 2017.7.2 and later | Supported in all releases |
|
||||
+===================================+=================================+
|
||||
| :: | :: |
|
||||
| | |
|
||||
| remove_key: | remove_key: |
|
||||
| wheel.key.delete: | wheel.key.delete: |
|
||||
| - args: | - match: {{ data['id'] }} |
|
||||
| - match: {{ data['id'] }} | |
|
||||
+-----------------------------------+---------------------------------+
|
||||
|
||||
.. _reactor-caller:
|
||||
|
||||
Caller Reactions
|
||||
----------------
|
||||
|
||||
Caller reactions run :ref:`remote-execution functions <all-salt.modules>` on a
|
||||
minion daemon's Reactor system. To run a Reactor on the minion, it is necessary
|
||||
to configure the :mod:`Reactor Engine <salt.engines.reactor>` in the minion
|
||||
config file, and then setup your watched events in a ``reactor`` section in the
|
||||
minion config file as well.
|
||||
|
||||
.. note:: Masterless Minions use this Reactor
|
||||
|
||||
This is the only way to run the Reactor if you use masterless minions.
|
||||
|
||||
Both the old and new config schemas involve passing arguments under an ``args``
|
||||
parameter. However, the old config schema only supports positional arguments.
|
||||
Therefore, the new config schema is recommended if the masterless minion is
|
||||
running a supported release.
|
||||
|
||||
The below two examples are equivalent:
|
||||
|
||||
+---------------------------------+---------------------------+
|
||||
| Supported in 2017.7.2 and later | Supported in all releases |
|
||||
+=================================+===========================+
|
||||
| :: | :: |
|
||||
| | |
|
||||
| touch_file: | touch_file: |
|
||||
| caller.file.touch: | caller.file.touch: |
|
||||
| - args: | - args: |
|
||||
| - name: /tmp/foo | - /tmp/foo |
|
||||
+---------------------------------+---------------------------+
|
||||
|
||||
This reaction is equvalent to running the following Salt command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt-call file.touch name=/tmp/foo
|
||||
|
||||
Best Practices for Writing Reactor SLS Files
|
||||
============================================
|
||||
|
||||
The Reactor works as follows:
|
||||
|
||||
1. The Salt Reactor watches Salt's event bus for new events.
|
||||
2. Each event's tag is matched against the list of event tags configured under
|
||||
the :conf_master:`reactor` section in the Salt Master config.
|
||||
3. The SLS files for any matches are rendered into a data structure that
|
||||
represents one or more function calls.
|
||||
4. That data structure is given to a pool of worker threads for execution.
|
||||
|
||||
Matching and rendering Reactor SLS files is done sequentially in a single
|
||||
process. Complex Jinja that calls out to slow Execution or Runner modules slows
|
||||
down the rendering and causes other reactions to pile up behind the current
|
||||
one. The worker pool is designed to handle complex and long-running processes
|
||||
such as Salt Orchestrate.
|
||||
process. For that reason, reactor SLS files should contain few individual
|
||||
reactions (one, if at all possible). Also, keep in mind that reactions are
|
||||
fired asynchronously (with the exception of :ref:`caller <reactor-caller>`) and
|
||||
do *not* support :ref:`requisites <requisites>`.
|
||||
|
||||
tl;dr: Rendering Reactor SLS files MUST be simple and quick. The new process
|
||||
started by the worker threads can be long-running. Using the reactor to fire
|
||||
an orchestrate runner would be ideal.
|
||||
Complex Jinja templating that calls out to slow :ref:`remote-execution
|
||||
<all-salt.modules>` or :ref:`runner <all-salt.runners>` functions slows down
|
||||
the rendering and causes other reactions to pile up behind the current one. The
|
||||
worker pool is designed to handle complex and long-running processes like
|
||||
:ref:`orchestration <orchestrate-runner>` jobs.
|
||||
|
||||
Therefore, when complex tasks are in order, :ref:`orchestration
|
||||
<orchestrate-runner>` is a natural fit. Orchestration SLS files can be more
|
||||
complex, and use requisites. Performing a complex task using orchestration lets
|
||||
the Reactor system fire off the orchestration job and proceed with processing
|
||||
other reactions.
|
||||
|
||||
.. _reactor-jinja-context:
|
||||
|
||||
Jinja Context
|
||||
-------------
|
||||
=============
|
||||
|
||||
Reactor files only have access to a minimal Jinja context. ``grains`` and
|
||||
``pillar`` are not available. The ``salt`` object is available for calling
|
||||
Runner and Execution modules but it should be used sparingly and only for quick
|
||||
tasks for the reasons mentioned above.
|
||||
Reactor SLS files only have access to a minimal Jinja context. ``grains`` and
|
||||
``pillar`` are *not* available. The ``salt`` object is available for calling
|
||||
:ref:`remote-execution <all-salt.modules>` or :ref:`runner <all-salt.runners>`
|
||||
functions, but it should be used sparingly and only for quick tasks for the
|
||||
reasons mentioned above.
|
||||
|
||||
In addition to the ``salt`` object, the following variables are available in
|
||||
the Jinja context:
|
||||
|
||||
- ``tag`` - the tag from the event that triggered execution of the Reactor SLS
|
||||
file
|
||||
- ``data`` - the event's data dictionary
|
||||
|
||||
The ``data`` dict will contain an ``id`` key containing the minion ID, if the
|
||||
event was fired from a minion, and a ``data`` key containing the data passed to
|
||||
the event.
|
||||
|
||||
Advanced State System Capabilities
|
||||
----------------------------------
|
||||
==================================
|
||||
|
||||
Reactor SLS files, by design, do not support Requisites, ordering,
|
||||
``onlyif``/``unless`` conditionals and most other powerful constructs from
|
||||
Salt's State system.
|
||||
Reactor SLS files, by design, do not support :ref:`requisites <requisites>`,
|
||||
ordering, ``onlyif``/``unless`` conditionals and most other powerful constructs
|
||||
from Salt's State system.
|
||||
|
||||
Complex Master-side operations are best performed by Salt's Orchestrate system
|
||||
so using the Reactor to kick off an Orchestrate run is a very common pairing.
|
||||
|
|
@ -166,7 +370,7 @@ For example:
|
|||
# /etc/salt/master.d/reactor.conf
|
||||
# A custom event containing: {"foo": "Foo!", "bar: "bar*", "baz": "Baz!"}
|
||||
reactor:
|
||||
- myco/custom/event:
|
||||
- my/custom/event:
|
||||
- /srv/reactor/some_event.sls
|
||||
|
||||
.. code-block:: jinja
|
||||
|
|
@ -174,15 +378,15 @@ For example:
|
|||
# /srv/reactor/some_event.sls
|
||||
invoke_orchestrate_file:
|
||||
runner.state.orchestrate:
|
||||
- mods: _orch.do_complex_thing # /srv/salt/_orch/do_complex_thing.sls
|
||||
- kwarg:
|
||||
pillar:
|
||||
event_tag: {{ tag }}
|
||||
event_data: {{ data|json() }}
|
||||
- args:
|
||||
- mods: orchestrate.do_complex_thing
|
||||
- pillar:
|
||||
event_tag: {{ tag }}
|
||||
event_data: {{ data|json }}
|
||||
|
||||
.. code-block:: jinja
|
||||
|
||||
# /srv/salt/_orch/do_complex_thing.sls
|
||||
# /srv/salt/orchestrate/do_complex_thing.sls
|
||||
{% set tag = salt.pillar.get('event_tag') %}
|
||||
{% set data = salt.pillar.get('event_data') %}
|
||||
|
||||
|
|
@ -209,7 +413,7 @@ For example:
|
|||
.. _beacons-and-reactors:
|
||||
|
||||
Beacons and Reactors
|
||||
--------------------
|
||||
====================
|
||||
|
||||
An event initiated by a beacon, when it arrives at the master will be wrapped
|
||||
inside a second event, such that the data object containing the beacon
|
||||
|
|
@ -219,27 +423,52 @@ For example, to access the ``id`` field of the beacon event in a reactor file,
|
|||
you will need to reference ``{{ data['data']['id'] }}`` rather than ``{{
|
||||
data['id'] }}`` as for events initiated directly on the event bus.
|
||||
|
||||
Similarly, the data dictionary attached to the event would be located in
|
||||
``{{ data['data']['data'] }}`` instead of ``{{ data['data'] }}``.
|
||||
|
||||
See the :ref:`beacon documentation <beacon-example>` for examples.
|
||||
|
||||
Fire an event
|
||||
=============
|
||||
Manually Firing an Event
|
||||
========================
|
||||
|
||||
To fire an event from a minion call ``event.send``
|
||||
From the Master
|
||||
---------------
|
||||
|
||||
Use the :py:func:`event.send <salt.runners.event.send>` runner:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt-call event.send 'foo' '{orchestrate: refresh}'
|
||||
salt-run event.send foo '{orchestrate: refresh}'
|
||||
|
||||
After this is called, any reactor sls files matching event tag ``foo`` will
|
||||
execute with ``{{ data['data']['orchestrate'] }}`` equal to ``'refresh'``.
|
||||
From the Minion
|
||||
---------------
|
||||
|
||||
See :py:mod:`salt.modules.event` for more information.
|
||||
To fire an event to the master from a minion, call :py:func:`event.send
|
||||
<salt.modules.event.send>`:
|
||||
|
||||
Knowing what event is being fired
|
||||
=================================
|
||||
.. code-block:: bash
|
||||
|
||||
The best way to see exactly what events are fired and what data is available in
|
||||
each event is to use the :py:func:`state.event runner
|
||||
salt-call event.send foo '{orchestrate: refresh}'
|
||||
|
||||
To fire an event to the minion's local event bus, call :py:func:`event.fire
|
||||
<salt.modules.event.fire>`:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt-call event.fire '{orchestrate: refresh}' foo
|
||||
|
||||
Referencing Data Passed in Events
|
||||
---------------------------------
|
||||
|
||||
Assuming any of the above examples, any reactor SLS files triggered by watching
|
||||
the event tag ``foo`` will execute with ``{{ data['data']['orchestrate'] }}``
|
||||
equal to ``'refresh'``.
|
||||
|
||||
Getting Information About Events
|
||||
================================
|
||||
|
||||
The best way to see exactly what events have been fired and what data is
|
||||
available in each event is to use the :py:func:`state.event runner
|
||||
<salt.runners.state.event>`.
|
||||
|
||||
.. seealso:: :ref:`Common Salt Events <event-master_events>`
|
||||
|
|
@ -308,156 +537,10 @@ rendered SLS file (or any errors generated while rendering the SLS file).
|
|||
view the result of referencing Jinja variables. If the result is empty then
|
||||
Jinja produced an empty result and the Reactor will ignore it.
|
||||
|
||||
.. _reactor-structure:
|
||||
Passing Event Data to Minions or Orchestration as Pillar
|
||||
--------------------------------------------------------
|
||||
|
||||
Understanding the Structure of Reactor Formulas
|
||||
===============================================
|
||||
|
||||
**I.e., when to use `arg` and `kwarg` and when to specify the function
|
||||
arguments directly.**
|
||||
|
||||
While the reactor system uses the same basic data structure as the state
|
||||
system, the functions that will be called using that data structure are
|
||||
different functions than are called via Salt's state system. The Reactor can
|
||||
call Runner modules using the `runner` prefix, Wheel modules using the `wheel`
|
||||
prefix, and can also cause minions to run Execution modules using the `local`
|
||||
prefix.
|
||||
|
||||
.. versionchanged:: 2014.7.0
|
||||
The ``cmd`` prefix was renamed to ``local`` for consistency with other
|
||||
parts of Salt. A backward-compatible alias was added for ``cmd``.
|
||||
|
||||
The Reactor runs on the master and calls functions that exist on the master. In
|
||||
the case of Runner and Wheel functions the Reactor can just call those
|
||||
functions directly since they exist on the master and are run on the master.
|
||||
|
||||
In the case of functions that exist on minions and are run on minions, the
|
||||
Reactor still needs to call a function on the master in order to send the
|
||||
necessary data to the minion so the minion can execute that function.
|
||||
|
||||
The Reactor calls functions exposed in :ref:`Salt's Python API documentation
|
||||
<client-apis>`. and thus the structure of Reactor files very transparently
|
||||
reflects the function signatures of those functions.
|
||||
|
||||
Calling Execution modules on Minions
|
||||
------------------------------------
|
||||
|
||||
The Reactor sends commands down to minions in the exact same way Salt's CLI
|
||||
interface does. It calls a function locally on the master that sends the name
|
||||
of the function as well as a list of any arguments and a dictionary of any
|
||||
keyword arguments that the minion should use to execute that function.
|
||||
|
||||
Specifically, the Reactor calls the async version of :py:meth:`this function
|
||||
<salt.client.LocalClient.cmd>`. You can see that function has 'arg' and 'kwarg'
|
||||
parameters which are both values that are sent down to the minion.
|
||||
|
||||
Executing remote commands maps to the :strong:`LocalClient` interface which is
|
||||
used by the :strong:`salt` command. This interface more specifically maps to
|
||||
the :strong:`cmd_async` method inside of the :strong:`LocalClient` class. This
|
||||
means that the arguments passed are being passed to the :strong:`cmd_async`
|
||||
method, not the remote method. A field starts with :strong:`local` to use the
|
||||
:strong:`LocalClient` subsystem. The result is, to execute a remote command,
|
||||
a reactor formula would look like this:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
clean_tmp:
|
||||
local.cmd.run:
|
||||
- tgt: '*'
|
||||
- arg:
|
||||
- rm -rf /tmp/*
|
||||
|
||||
The ``arg`` option takes a list of arguments as they would be presented on the
|
||||
command line, so the above declaration is the same as running this salt
|
||||
command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt '*' cmd.run 'rm -rf /tmp/*'
|
||||
|
||||
Use the ``tgt_type`` argument to specify a matcher:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
clean_tmp:
|
||||
local.cmd.run:
|
||||
- tgt: 'os:Ubuntu'
|
||||
- tgt_type: grain
|
||||
- arg:
|
||||
- rm -rf /tmp/*
|
||||
|
||||
|
||||
clean_tmp:
|
||||
local.cmd.run:
|
||||
- tgt: 'G@roles:hbase_master'
|
||||
- tgt_type: compound
|
||||
- arg:
|
||||
- rm -rf /tmp/*
|
||||
|
||||
.. note::
|
||||
The ``tgt_type`` argument was named ``expr_form`` in releases prior to
|
||||
2017.7.0 (2016.11.x and earlier).
|
||||
|
||||
Any other parameters in the :py:meth:`LocalClient().cmd()
|
||||
<salt.client.LocalClient.cmd>` method can be specified as well.
|
||||
|
||||
Executing Reactors from the Minion
|
||||
----------------------------------
|
||||
|
||||
The minion can be setup to use the Reactor via a reactor engine. This just
|
||||
sets up and listens to the minions event bus, instead of to the masters.
|
||||
|
||||
The biggest difference is that you have to use the caller method on the
|
||||
Reactor, which is the equivalent of salt-call, to run your commands.
|
||||
|
||||
:mod:`Reactor Engine setup <salt.engines.reactor>`
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
clean_tmp:
|
||||
caller.cmd.run:
|
||||
- arg:
|
||||
- rm -rf /tmp/*
|
||||
|
||||
.. note:: Masterless Minions use this Reactor
|
||||
|
||||
This is the only way to run the Reactor if you use masterless minions.
|
||||
|
||||
Calling Runner modules and Wheel modules
|
||||
----------------------------------------
|
||||
|
||||
Calling Runner modules and Wheel modules from the Reactor uses a more direct
|
||||
syntax since the function is being executed locally instead of sending a
|
||||
command to a remote system to be executed there. There are no 'arg' or 'kwarg'
|
||||
parameters (unless the Runner function or Wheel function accepts a parameter
|
||||
with either of those names.)
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
clear_the_grains_cache_for_all_minions:
|
||||
runner.cache.clear_grains
|
||||
|
||||
If the :py:func:`the runner takes arguments <salt.runners.cloud.profile>` then
|
||||
they must be specified as keyword arguments.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
spin_up_more_web_machines:
|
||||
runner.cloud.profile:
|
||||
- prof: centos_6
|
||||
- instances:
|
||||
- web11 # These VM names would be generated via Jinja in a
|
||||
- web12 # real-world example.
|
||||
|
||||
To determine the proper names for the arguments, check the documentation
|
||||
or source code for the runner function you wish to call.
|
||||
|
||||
Passing event data to Minions or Orchestrate as Pillar
|
||||
------------------------------------------------------
|
||||
|
||||
An interesting trick to pass data from the Reactor script to
|
||||
An interesting trick to pass data from the Reactor SLS file to
|
||||
:py:func:`state.apply <salt.modules.state.apply_>` is to pass it as inline
|
||||
Pillar data since both functions take a keyword argument named ``pillar``.
|
||||
|
||||
|
|
@ -484,10 +567,9 @@ from the event to the state file via inline Pillar.
|
|||
add_new_minion_to_pool:
|
||||
local.state.apply:
|
||||
- tgt: 'haproxy*'
|
||||
- arg:
|
||||
- haproxy.refresh_pool
|
||||
- kwarg:
|
||||
pillar:
|
||||
- args:
|
||||
- mods: haproxy.refresh_pool
|
||||
- pillar:
|
||||
new_minion: {{ data['id'] }}
|
||||
{% endif %}
|
||||
|
||||
|
|
@ -503,17 +585,16 @@ This works with Orchestrate files as well:
|
|||
|
||||
call_some_orchestrate_file:
|
||||
runner.state.orchestrate:
|
||||
- mods: _orch.some_orchestrate_file
|
||||
- pillar:
|
||||
stuff: things
|
||||
- args:
|
||||
- mods: orchestrate.some_orchestrate_file
|
||||
- pillar:
|
||||
stuff: things
|
||||
|
||||
Which is equivalent to the following command at the CLI:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt-run state.orchestrate _orch.some_orchestrate_file pillar='{stuff: things}'
|
||||
|
||||
This expects to find a file at /srv/salt/_orch/some_orchestrate_file.sls.
|
||||
salt-run state.orchestrate orchestrate.some_orchestrate_file pillar='{stuff: things}'
|
||||
|
||||
Finally, that data is available in the state file using the normal Pillar
|
||||
lookup syntax. The following example is grabbing web server names and IP
|
||||
|
|
@ -564,7 +645,7 @@ includes the minion id, which we can use for matching.
|
|||
- 'salt/minion/ink*/start':
|
||||
- /srv/reactor/auth-complete.sls
|
||||
|
||||
In this sls file, we say that if the key was rejected we will delete the key on
|
||||
In this SLS file, we say that if the key was rejected we will delete the key on
|
||||
the master and then also tell the master to ssh in to the minion and tell it to
|
||||
restart the minion, since a minion process will die if the key is rejected.
|
||||
|
||||
|
|
@ -580,19 +661,21 @@ authentication every ten seconds by default.
|
|||
{% if not data['result'] and data['id'].startswith('ink') %}
|
||||
minion_remove:
|
||||
wheel.key.delete:
|
||||
- match: {{ data['id'] }}
|
||||
- args:
|
||||
- match: {{ data['id'] }}
|
||||
minion_rejoin:
|
||||
local.cmd.run:
|
||||
- tgt: salt-master.domain.tld
|
||||
- arg:
|
||||
- ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no "{{ data['id'] }}" 'sleep 10 && /etc/init.d/salt-minion restart'
|
||||
- args:
|
||||
- cmd: ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no "{{ data['id'] }}" 'sleep 10 && /etc/init.d/salt-minion restart'
|
||||
{% endif %}
|
||||
|
||||
{# Ink server is sending new key -- accept this key #}
|
||||
{% if 'act' in data and data['act'] == 'pend' and data['id'].startswith('ink') %}
|
||||
minion_add:
|
||||
wheel.key.accept:
|
||||
- match: {{ data['id'] }}
|
||||
- args:
|
||||
- match: {{ data['id'] }}
|
||||
{% endif %}
|
||||
|
||||
No if statements are needed here because we already limited this action to just
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ bringing with it the ability to access authenticated repositories.
|
|||
|
||||
Using the new features will require updates to the git ext_pillar
|
||||
configuration, further details can be found in the :ref:`pillar.git_pillar
|
||||
<git-pillar-2015-8-0-and-later>` docs.
|
||||
<git-pillar-configuration>` docs.
|
||||
|
||||
.. _pygit2: https://github.com/libgit2/pygit2
|
||||
|
||||
|
|
|
|||
|
|
@ -3,3 +3,13 @@ Salt 2016.11.7 Release Notes
|
|||
============================
|
||||
|
||||
Version 2016.11.7 is a bugfix release for :ref:`2016.11.0 <release-2016-11-0>`.
|
||||
|
||||
Changes for v2016.11.6..v2016.11.7
|
||||
----------------------------------
|
||||
|
||||
Security Fix
|
||||
============
|
||||
|
||||
CVE-2017-12791 Maliciously crafted minion IDs can cause unwanted directory traversals on the Salt-master
|
||||
|
||||
Correct a flaw in minion id validation which could allow certain minions to authenticate to a master despite not having the correct credentials. To exploit the vulnerability, an attacker must create a salt-minion with an ID containing characters that will cause a directory traversal. Credit for discovering the security flaw goes to: Vernhk@qq.com
|
||||
|
|
|
|||
1719
doc/topics/releases/2016.11.8.rst
Normal file
1719
doc/topics/releases/2016.11.8.rst
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -175,6 +175,10 @@ they are being loaded for the correct proxytype, example below:
|
|||
|
||||
return False
|
||||
|
||||
.. note::
|
||||
``salt.utils.is_proxy()`` has been renamed to
|
||||
``salt.utils.platform.is_proxy`` as of the Oxygen release.
|
||||
|
||||
The try/except block above exists because grains are processed very early
|
||||
in the proxy minion startup process, sometimes earlier than the proxy
|
||||
key in the ``__opts__`` dictionary is populated.
|
||||
|
|
|
|||
|
|
@ -4,23 +4,12 @@ Salt 2016.3.7 Release Notes
|
|||
|
||||
Version 2016.3.7 is a bugfix release for :ref:`2016.3.0 <release-2016-3-0>`.
|
||||
|
||||
New master configuration option `allow_minion_key_revoke`, defaults to True. This option
|
||||
controls whether a minion can request that the master revoke its key. When True, a minion
|
||||
can request a key revocation and the master will comply. If it is False, the key will not
|
||||
be revoked by the msater.
|
||||
Changes for v2016.3.6..v2016.3.7
|
||||
--------------------------------
|
||||
|
||||
New master configuration option `require_minion_sign_messages`
|
||||
This requires that minions cryptographically sign the messages they
|
||||
publish to the master. If minions are not signing, then log this information
|
||||
at loglevel 'INFO' and drop the message without acting on it.
|
||||
Security Fix
|
||||
============
|
||||
|
||||
New master configuration option `drop_messages_signature_fail`
|
||||
Drop messages from minions when their signatures do not validate.
|
||||
Note that when this option is False but `require_minion_sign_messages` is True
|
||||
minions MUST sign their messages but the validity of their signatures
|
||||
is ignored.
|
||||
CVE-2017-12791 Maliciously crafted minion IDs can cause unwanted directory traversals on the Salt-master
|
||||
|
||||
New minion configuration option `minion_sign_messages`
|
||||
Causes the minion to cryptographically sign the payload of messages it places
|
||||
on the event bus for the master. The payloads are signed with the minion's
|
||||
private key so the master can verify the signature with its public key.
|
||||
Correct a flaw in minion id validation which could allow certain minions to authenticate to a master despite not having the correct credentials. To exploit the vulnerability, an attacker must create a salt-minion with an ID containing characters that will cause a directory traversal. Credit for discovering the security flaw goes to: Vernhk@qq.com
|
||||
|
|
|
|||
29
doc/topics/releases/2016.3.8.rst
Normal file
29
doc/topics/releases/2016.3.8.rst
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
===========================
|
||||
Salt 2016.3.8 Release Notes
|
||||
===========================
|
||||
|
||||
Version 2016.3.8 is a bugfix release for :ref:`2016.3.0 <release-2016-3-0>`.
|
||||
|
||||
Changes for v2016.3.7..v2016.3.8
|
||||
--------------------------------
|
||||
|
||||
New master configuration option `allow_minion_key_revoke`, defaults to True. This option
|
||||
controls whether a minion can request that the master revoke its key. When True, a minion
|
||||
can request a key revocation and the master will comply. If it is False, the key will not
|
||||
be revoked by the msater.
|
||||
|
||||
New master configuration option `require_minion_sign_messages`
|
||||
This requires that minions cryptographically sign the messages they
|
||||
publish to the master. If minions are not signing, then log this information
|
||||
at loglevel 'INFO' and drop the message without acting on it.
|
||||
|
||||
New master configuration option `drop_messages_signature_fail`
|
||||
Drop messages from minions when their signatures do not validate.
|
||||
Note that when this option is False but `require_minion_sign_messages` is True
|
||||
minions MUST sign their messages but the validity of their signatures
|
||||
is ignored.
|
||||
|
||||
New minion configuration option `minion_sign_messages`
|
||||
Causes the minion to cryptographically sign the payload of messages it places
|
||||
on the event bus for the master. The payloads are signed with the minion's
|
||||
private key so the master can verify the signature with its public key.
|
||||
|
|
@ -122,13 +122,12 @@ State Module Changes
|
|||
# After
|
||||
run_something:
|
||||
module.run:
|
||||
mymodule.something:
|
||||
- mymodule.something:
|
||||
- name: some name
|
||||
- first_arg: one
|
||||
- second_arg: two
|
||||
- do_stuff: True
|
||||
|
||||
|
||||
Since a lot of users are already using :py:func:`module.run
|
||||
<salt.states.module.run>` states, this new behavior must currently be
|
||||
explicitly turned on, to allow users to take their time updating their SLS
|
||||
|
|
@ -136,6 +135,36 @@ State Module Changes
|
|||
the next feature release of Salt (Oxygen) and the old usage will no longer be
|
||||
supported at that time.
|
||||
|
||||
Another feature of the new :py:func:`module.run <salt.states.module.run>` is that
|
||||
it allows calling many functions in a single batch, such as:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
run_something:
|
||||
module.run:
|
||||
- mymodule.function_without_parameters:
|
||||
- mymodule.another_function:
|
||||
- myparam
|
||||
- my_other_param
|
||||
|
||||
In a rare case that you have a function that needs to be called several times but
|
||||
with the different parameters, an additional feature of "tagging" is to the
|
||||
rescue. In order to tag a function, use a colon delimeter. For example:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
run_something:
|
||||
module.run:
|
||||
- mymodule.same_function:1:
|
||||
- mymodule.same_function:2:
|
||||
- myparam
|
||||
- my_other_param
|
||||
- mymodule.same_function:3:
|
||||
- foo: bar
|
||||
|
||||
The example above will run `mymodule.same_function` three times with the
|
||||
different parameters.
|
||||
|
||||
To enable the new behavior for :py:func:`module.run <salt.states.module.run>`,
|
||||
add the following to the minion config file:
|
||||
|
||||
|
|
@ -143,6 +172,7 @@ State Module Changes
|
|||
|
||||
use_superseded:
|
||||
- module.run
|
||||
|
||||
- The default for the ``fingerprint_hash_type`` option used in the ``present``
|
||||
function in the :mod:`ssh <salt.states.ssh_know_hosts>` state changed from
|
||||
``md5`` to ``sha256``.
|
||||
|
|
@ -676,6 +706,7 @@ Execution modules
|
|||
- :mod:`salt.modules.grafana4 <salt.modules.grafana4>`
|
||||
- :mod:`salt.modules.heat <salt.modules.heat>`
|
||||
- :mod:`salt.modules.icinga2 <salt.modules.icinga2>`
|
||||
- :mod:`salt.modules.kubernetes <salt.modules.kubernetes>`
|
||||
- :mod:`salt.modules.logmod <salt.modules.logmod>`
|
||||
- :mod:`salt.modules.mattermost <salt.modules.mattermost>`
|
||||
- :mod:`salt.modules.namecheap_dns <salt.modules.namecheap_dns>`
|
||||
|
|
@ -754,6 +785,7 @@ States
|
|||
- :mod:`salt.states.icinga2 <salt.states.icinga2>`
|
||||
- :mod:`salt.states.influxdb_continuous_query <salt.states.influxdb_continuous_query>`
|
||||
- :mod:`salt.states.influxdb_retention_policy <salt.states.influxdb_retention_policy>`
|
||||
- :mod:`salt.states.kubernetes <salt.states.kubernetes>`
|
||||
- :mod:`salt.states.logadm <salt.states.logadm>`
|
||||
- :mod:`salt.states.logrotate <salt.states.logrotate>`
|
||||
- :mod:`salt.states.msteams <salt.states.msteams>`
|
||||
|
|
|
|||
|
|
@ -4,6 +4,13 @@ Salt 2017.7.1 Release Notes
|
|||
|
||||
Version 2017.7.1 is a bugfix release for :ref:`2017.7.0 <release-2017-7-0>`.
|
||||
|
||||
Security Fix
|
||||
============
|
||||
|
||||
CVE-2017-12791 Maliciously crafted minion IDs can cause unwanted directory traversals on the Salt-master
|
||||
|
||||
Correct a flaw in minion id validation which could allow certain minions to authenticate to a master despite not having the correct credentials. To exploit the vulnerability, an attacker must create a salt-minion with an ID containing characters that will cause a directory traversal. Credit for discovering the security flaw goes to: Vernhk@qq.com
|
||||
|
||||
Changes for v2017.7.0..v2017.7.1
|
||||
--------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -8,17 +8,17 @@ Comparison Operators in Package Installation
|
|||
--------------------------------------------
|
||||
|
||||
Salt now supports using comparison operators (e.g. ``>=1.2.3``) when installing
|
||||
packages on minions which use :mod:`yum/dnf <salt.modules.yumpkg>` or :mod:`apt
|
||||
<salt.modules.aptpkg>`. This is supported both in the :py:func:`pkg.installed
|
||||
<salt.states.pkg.installed>` state and in the ``pkg.install`` remote execution
|
||||
function.
|
||||
packages on minions which use :mod:`yum/dnf <salt.modules.yumpkg>` or
|
||||
:mod:`apt <salt.modules.aptpkg>`. This is supported both in the
|
||||
:py:func:`pkg.installed <salt.states.pkg.installed>` state and in the ``pkg.install``
|
||||
remote execution function.
|
||||
|
||||
:ref:`Master Tops <master-tops-system>` Changes
|
||||
-----------------------------------------------
|
||||
|
||||
When both :ref:`Master Tops <master-tops-system>` and a :ref:`Top File
|
||||
<states-top>` produce SLS matches for a given minion, the matches were being
|
||||
merged in an unpredictable manner which did not preserve ordering. This has
|
||||
When both :ref:`Master Tops <master-tops-system>` and a
|
||||
:ref:`Top File <states-top>` produce SLS matches for a given minion, the matches
|
||||
were being merged in an unpredictable manner which did not preserve ordering. This has
|
||||
been changed. The top file matches now execute in the expected order, followed
|
||||
by any master tops matches that are not matched via a top file.
|
||||
|
||||
|
|
@ -38,6 +38,47 @@ In previous releases the bind credentials would only be used to determine
|
|||
the LDAP user's existence and group membership. The user's LDAP credentials
|
||||
were used from then on.
|
||||
|
||||
Stormpath External Authentication Removed
|
||||
-----------------------------------------
|
||||
|
||||
Per Stormpath's announcement, their API will be shutting down on 8/17/2017 at
|
||||
noon PST so the Stormpath external authentication module has been removed.
|
||||
|
||||
https://stormpath.com/oktaplusstormpath
|
||||
|
||||
New Grains
|
||||
----------
|
||||
|
||||
New core grains have been added to expose any storage inititator setting.
|
||||
|
||||
The new grains added are:
|
||||
|
||||
* ``fc_wwn``: Show all fibre channel world wide port names for a host
|
||||
* ``iscsi_iqn``: Show the iSCSI IQN name for a host
|
||||
|
||||
New Modules
|
||||
-----------
|
||||
|
||||
- :mod:`salt.modules.purefa <salt.modules.purefa>`
|
||||
|
||||
New NaCl Renderer
|
||||
-----------------
|
||||
|
||||
A new renderer has been added for encrypted data.
|
||||
|
||||
New support for Cisco UCS Chassis
|
||||
---------------------------------
|
||||
|
||||
The salt proxy minion now allows for control of Cisco USC chassis. See
|
||||
the ``cimc`` modules for details.
|
||||
|
||||
New salt-ssh roster
|
||||
-------------------
|
||||
|
||||
A new roster has been added that allows users to pull in a list of hosts
|
||||
for salt-ssh targeting from a ``~/.ssh`` configuration. For full details,
|
||||
please see the ``sshconfig`` roster.
|
||||
|
||||
New GitFS Features
|
||||
------------------
|
||||
|
||||
|
|
@ -62,11 +103,18 @@ environments (i.e. ``saltenvs``) have been added:
|
|||
ignore all tags and use branches only, and also to keep SHAs from being made
|
||||
available as saltenvs.
|
||||
|
||||
Additional output modes
|
||||
------------------
|
||||
|
||||
The ``state_output`` parameter now supports ``full_id``, ``changes_id`` and ``terse_id``.
|
||||
Just like ``mixed_id``, these use the state ID as name in the highstate output.
|
||||
For more information on these output modes, see the docs for the :mod:`Highstate Outputter <salt.output.highstate>`.
|
||||
|
||||
Salt Cloud Features
|
||||
===================
|
||||
-------------------
|
||||
|
||||
Pre-Flight Commands
|
||||
-------------------
|
||||
===================
|
||||
|
||||
Support has been added for specified "preflight commands" to run on a VM before
|
||||
the deploy script is run. These must be defined as a list in a cloud configuration
|
||||
|
|
@ -84,12 +132,208 @@ file. For example:
|
|||
|
||||
These commands will run in sequence **before** the bootstrap script is executed.
|
||||
|
||||
New pillar/master_tops module called saltclass
|
||||
----------------------------------------------
|
||||
|
||||
This module clones the behaviour of reclass (http://reclass.pantsfullofunix.net/), without the need of an external app, and add several features to improve flexibility.
|
||||
Saltclass lets you define your nodes from simple ``yaml`` files (``.yml``) through hierarchical class inheritance with the possibility to override pillars down the tree.
|
||||
|
||||
**Features**
|
||||
|
||||
- Define your nodes through hierarchical class inheritance
|
||||
- Reuse your reclass datas with minimal modifications
|
||||
- applications => states
|
||||
- parameters => pillars
|
||||
- Use Jinja templating in your yaml definitions
|
||||
- Access to the following Salt objects in Jinja
|
||||
- ``__opts__``
|
||||
- ``__salt__``
|
||||
- ``__grains__``
|
||||
- ``__pillars__``
|
||||
- ``minion_id``
|
||||
- Chose how to merge or override your lists using ^ character (see examples)
|
||||
- Expand variables ${} with possibility to escape them if needed \${} (see examples)
|
||||
- Ignores missing node/class and will simply return empty without breaking the pillar module completely - will be logged
|
||||
|
||||
An example subset of datas is available here: http://git.mauras.ch/salt/saltclass/src/master/examples
|
||||
|
||||
========================== ===========
|
||||
Terms usable in yaml files Description
|
||||
========================== ===========
|
||||
classes A list of classes that will be processed in order
|
||||
states A list of states that will be returned by master_tops function
|
||||
pillars A yaml dictionnary that will be returned by the ext_pillar function
|
||||
environment Node saltenv that will be used by master_tops
|
||||
========================== ===========
|
||||
|
||||
A class consists of:
|
||||
|
||||
- zero or more parent classes
|
||||
- zero or more states
|
||||
- any number of pillars
|
||||
|
||||
A child class can override pillars from a parent class.
|
||||
A node definition is a class in itself with an added ``environment`` parameter for ``saltenv`` definition.
|
||||
|
||||
**class names**
|
||||
|
||||
Class names mimic salt way of defining states and pillar files.
|
||||
This means that ``default.users`` class name will correspond to one of these:
|
||||
|
||||
- ``<saltclass_path>/classes/default/users.yml``
|
||||
- ``<saltclass_path>/classes/default/users/init.yml``
|
||||
|
||||
**Saltclass tree**
|
||||
|
||||
A saltclass tree would look like this:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
<saltclass_path>
|
||||
├── classes
|
||||
│ ├── app
|
||||
│ │ ├── borgbackup.yml
|
||||
│ │ └── ssh
|
||||
│ │ └── server.yml
|
||||
│ ├── default
|
||||
│ │ ├── init.yml
|
||||
│ │ ├── motd.yml
|
||||
│ │ └── users.yml
|
||||
│ ├── roles
|
||||
│ │ ├── app.yml
|
||||
│ │ └── nginx
|
||||
│ │ ├── init.yml
|
||||
│ │ └── server.yml
|
||||
│ └── subsidiaries
|
||||
│ ├── gnv.yml
|
||||
│ ├── qls.yml
|
||||
│ └── zrh.yml
|
||||
└── nodes
|
||||
├── geneva
|
||||
│ └── gnv.node1.yml
|
||||
├── lausanne
|
||||
│ ├── qls.node1.yml
|
||||
│ └── qls.node2.yml
|
||||
├── node127.yml
|
||||
└── zurich
|
||||
├── zrh.node1.yml
|
||||
├── zrh.node2.yml
|
||||
└── zrh.node3.yml
|
||||
|
||||
**Examples**
|
||||
|
||||
``<saltclass_path>/nodes/lausanne/qls.node1.yml``
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
environment: base
|
||||
|
||||
classes:
|
||||
{% for class in ['default'] %}
|
||||
- {{ class }}
|
||||
{% endfor %}
|
||||
- subsidiaries.{{ __grains__['id'].split('.')[0] }}
|
||||
|
||||
``<saltclass_path>/classes/default/init.yml``
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
classes:
|
||||
- default.users
|
||||
- default.motd
|
||||
|
||||
states:
|
||||
- openssh
|
||||
|
||||
pillars:
|
||||
default:
|
||||
network:
|
||||
dns:
|
||||
srv1: 192.168.0.1
|
||||
srv2: 192.168.0.2
|
||||
domain: example.com
|
||||
ntp:
|
||||
srv1: 192.168.10.10
|
||||
srv2: 192.168.10.20
|
||||
|
||||
``<saltclass_path>/classes/subsidiaries/gnv.yml``
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
pillars:
|
||||
default:
|
||||
network:
|
||||
sub: Geneva
|
||||
dns:
|
||||
srv1: 10.20.0.1
|
||||
srv2: 10.20.0.2
|
||||
srv3: 192.168.1.1
|
||||
domain: gnv.example.com
|
||||
users:
|
||||
adm1:
|
||||
uid: 1210
|
||||
gid: 1210
|
||||
gecos: 'Super user admin1'
|
||||
homedir: /srv/app/adm1
|
||||
adm3:
|
||||
uid: 1203
|
||||
gid: 1203
|
||||
gecos: 'Super user adm
|
||||
|
||||
Variable expansions:
|
||||
|
||||
Escaped variables are rendered as is - ``${test}``
|
||||
|
||||
Missing variables are rendered as is - ``${net:dns:srv2}``
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
pillars:
|
||||
app:
|
||||
config:
|
||||
dns:
|
||||
srv1: ${default:network:dns:srv1}
|
||||
srv2: ${net:dns:srv2}
|
||||
uri: https://application.domain/call?\${test}
|
||||
prod_parameters:
|
||||
- p1
|
||||
- p2
|
||||
- p3
|
||||
pkg:
|
||||
- app-core
|
||||
- app-backend
|
||||
|
||||
List override:
|
||||
|
||||
Not using ``^`` as the first entry will simply merge the lists
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
pillars:
|
||||
app:
|
||||
pkg:
|
||||
- ^
|
||||
- app-frontend
|
||||
|
||||
|
||||
**Known limitation**
|
||||
|
||||
Currently you can't have both a variable and an escaped variable in the same string as the escaped one will not be correctly rendered - '\${xx}' will stay as is instead of being rendered as '${xx}'
|
||||
|
||||
Newer PyWinRM Versions
|
||||
----------------------
|
||||
|
||||
Versions of ``pywinrm>=0.2.1`` are finally able to disable validation of self
|
||||
signed certificates. :ref:`Here<new-pywinrm>` for more information.
|
||||
|
||||
DigitalOcean
|
||||
------------
|
||||
|
||||
The DigitalOcean driver has been renamed to conform to the companies name. The
|
||||
new driver name is ``digitalocean``. The old name ``digital_ocean`` and a
|
||||
short one ``do`` will still be supported through virtual aliases, this is mostly
|
||||
cosmetic.
|
||||
|
||||
Solaris Logical Domains In Virtual Grain
|
||||
----------------------------------------
|
||||
|
||||
|
|
@ -97,24 +341,565 @@ Support has been added to the ``virtual`` grain for detecting Solaris LDOMs
|
|||
running on T-Series SPARC hardware. The ``virtual_subtype`` grain is
|
||||
populated as a list of domain roles.
|
||||
|
||||
Lists of comments in state returns
|
||||
----------------------------------
|
||||
|
||||
State functions can now return a list of strings for the ``comment`` field,
|
||||
as opposed to only a single string.
|
||||
This is meant to ease writing states with multiple or multi-part comments.
|
||||
|
||||
Beacon configuration changes
|
||||
----------------------------
|
||||
|
||||
In order to remain consistent and to align with other Salt components such as states,
|
||||
support for configuring beacons using dictionary based configuration has been deprecated
|
||||
in favor of list based configuration. All beacons have a validation function which will
|
||||
check the configuration for the correct format and only load if the validation passes.
|
||||
|
||||
- ``avahi_announce`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
avahi_announce:
|
||||
run_once: True
|
||||
servicetype: _demo._tcp
|
||||
port: 1234
|
||||
txt:
|
||||
ProdName: grains.productname
|
||||
SerialNo: grains.serialnumber
|
||||
Comments: 'this is a test'
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
avahi_announce:
|
||||
- run_once: True
|
||||
- servicetype: _demo._tcp
|
||||
- port: 1234
|
||||
- txt:
|
||||
ProdName: grains.productname
|
||||
SerialNo: grains.serialnumber
|
||||
Comments: 'this is a test'
|
||||
|
||||
- ``bonjour_announce`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
bonjour_announce:
|
||||
run_once: True
|
||||
servicetype: _demo._tcp
|
||||
port: 1234
|
||||
txt:
|
||||
ProdName: grains.productname
|
||||
SerialNo: grains.serialnumber
|
||||
Comments: 'this is a test'
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
bonjour_announce:
|
||||
- run_once: True
|
||||
- servicetype: _demo._tcp
|
||||
- port: 1234
|
||||
- txt:
|
||||
ProdName: grains.productname
|
||||
SerialNo: grains.serialnumber
|
||||
Comments: 'this is a test'
|
||||
|
||||
- ``btmp`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
btmp: {}
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
btmp: []
|
||||
|
||||
- ``glxinfo`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
glxinfo:
|
||||
user: frank
|
||||
screen_event: True
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
glxinfo:
|
||||
- user: frank
|
||||
- screen_event: True
|
||||
|
||||
- ``haproxy`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
haproxy:
|
||||
- www-backend:
|
||||
threshold: 45
|
||||
servers:
|
||||
- web1
|
||||
- web2
|
||||
- interval: 120
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
haproxy:
|
||||
- backends:
|
||||
www-backend:
|
||||
threshold: 45
|
||||
servers:
|
||||
- web1
|
||||
- web2
|
||||
- interval: 120
|
||||
|
||||
- ``inotify`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
inotify:
|
||||
/path/to/file/or/dir:
|
||||
mask:
|
||||
- open
|
||||
- create
|
||||
- close_write
|
||||
recurse: True
|
||||
auto_add: True
|
||||
exclude:
|
||||
- /path/to/file/or/dir/exclude1
|
||||
- /path/to/file/or/dir/exclude2
|
||||
- /path/to/file/or/dir/regex[a-m]*$:
|
||||
regex: True
|
||||
coalesce: True
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
inotify:
|
||||
- files:
|
||||
/path/to/file/or/dir:
|
||||
mask:
|
||||
- open
|
||||
- create
|
||||
- close_write
|
||||
recurse: True
|
||||
auto_add: True
|
||||
exclude:
|
||||
- /path/to/file/or/dir/exclude1
|
||||
- /path/to/file/or/dir/exclude2
|
||||
- /path/to/file/or/dir/regex[a-m]*$:
|
||||
regex: True
|
||||
- coalesce: True
|
||||
|
||||
- ``journald`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
journald:
|
||||
sshd:
|
||||
SYSLOG_IDENTIFIER: sshd
|
||||
PRIORITY: 6
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
journald:
|
||||
- services:
|
||||
sshd:
|
||||
SYSLOG_IDENTIFIER: sshd
|
||||
PRIORITY: 6
|
||||
|
||||
- ``load`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
load:
|
||||
1m:
|
||||
- 0.0
|
||||
- 2.0
|
||||
5m:
|
||||
- 0.0
|
||||
- 1.5
|
||||
15m:
|
||||
- 0.1
|
||||
- 1.0
|
||||
emitatstartup: True
|
||||
onchangeonly: False
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
load:
|
||||
- averages:
|
||||
1m:
|
||||
- 0.0
|
||||
- 2.0
|
||||
5m:
|
||||
- 0.0
|
||||
- 1.5
|
||||
15m:
|
||||
- 0.1
|
||||
- 1.0
|
||||
- emitatstartup: True
|
||||
- onchangeonly: False
|
||||
|
||||
- ``log`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
log:
|
||||
file: <path>
|
||||
<tag>:
|
||||
regex: <pattern>
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
log:
|
||||
- file: <path>
|
||||
- tags:
|
||||
<tag>:
|
||||
regex: <pattern>
|
||||
|
||||
- ``network_info`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
network_info:
|
||||
- eth0:
|
||||
type: equal
|
||||
bytes_sent: 100000
|
||||
bytes_recv: 100000
|
||||
packets_sent: 100000
|
||||
packets_recv: 100000
|
||||
errin: 100
|
||||
errout: 100
|
||||
dropin: 100
|
||||
dropout: 100
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
network_info:
|
||||
- interfaces:
|
||||
eth0:
|
||||
type: equal
|
||||
bytes_sent: 100000
|
||||
bytes_recv: 100000
|
||||
packets_sent: 100000
|
||||
packets_recv: 100000
|
||||
errin: 100
|
||||
errout: 100
|
||||
dropin: 100
|
||||
dropout: 100
|
||||
|
||||
- ``network_settings`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
network_settings:
|
||||
eth0:
|
||||
ipaddr:
|
||||
promiscuity:
|
||||
onvalue: 1
|
||||
eth1:
|
||||
linkmode:
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
network_settings:
|
||||
- interfaces:
|
||||
- eth0:
|
||||
ipaddr:
|
||||
promiscuity:
|
||||
onvalue: 1
|
||||
- eth1:
|
||||
linkmode:
|
||||
|
||||
- ``proxy_example`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
proxy_example:
|
||||
endpoint: beacon
|
||||
```
|
||||
|
||||
New behavior:
|
||||
```
|
||||
beacons:
|
||||
proxy_example:
|
||||
- endpoint: beacon
|
||||
|
||||
- ``ps`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
ps:
|
||||
- salt-master: running
|
||||
- mysql: stopped
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
ps:
|
||||
- processes:
|
||||
salt-master: running
|
||||
mysql: stopped
|
||||
|
||||
- ``salt_proxy`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
salt_proxy:
|
||||
- p8000: {}
|
||||
- p8001: {}
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
salt_proxy:
|
||||
- proxies:
|
||||
p8000: {}
|
||||
p8001: {}
|
||||
|
||||
- ``sensehat`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
sensehat:
|
||||
humidity: 70%
|
||||
temperature: [20, 40]
|
||||
temperature_from_pressure: 40
|
||||
pressure: 1500
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
sensehat:
|
||||
- sensors:
|
||||
humidity: 70%
|
||||
temperature: [20, 40]
|
||||
temperature_from_pressure: 40
|
||||
pressure: 1500
|
||||
|
||||
- ``service`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
service:
|
||||
salt-master:
|
||||
mysql:
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
service:
|
||||
- services:
|
||||
nginx:
|
||||
onchangeonly: True
|
||||
delay: 30
|
||||
uncleanshutdown: /run/nginx.pid
|
||||
|
||||
- ``sh`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
sh: {}
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
sh: []
|
||||
|
||||
- ``status`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
status: {}
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
status: []
|
||||
|
||||
- ``telegram_bot_msg`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
telegram_bot_msg:
|
||||
token: "<bot access token>"
|
||||
accept_from:
|
||||
- "<valid username>"
|
||||
interval: 10
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
telegram_bot_msg:
|
||||
- token: "<bot access token>"
|
||||
- accept_from:
|
||||
- "<valid username>"
|
||||
- interval: 10
|
||||
|
||||
- ``twilio_txt_msg`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
twilio_txt_msg:
|
||||
account_sid: "<account sid>"
|
||||
auth_token: "<auth token>"
|
||||
twilio_number: "+15555555555"
|
||||
interval: 10
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
twilio_txt_msg:
|
||||
- account_sid: "<account sid>"
|
||||
- auth_token: "<auth token>"
|
||||
- twilio_number: "+15555555555"
|
||||
- interval: 10
|
||||
|
||||
- ``wtmp`` beacon
|
||||
|
||||
Old behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
wtmp: {}
|
||||
|
||||
New behavior:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
beacons:
|
||||
wtmp: []
|
||||
|
||||
Deprecations
|
||||
============
|
||||
------------
|
||||
|
||||
Configuration Option Deprecations
|
||||
---------------------------------
|
||||
=================================
|
||||
|
||||
- The ``requests_lib`` configuration option has been removed. Please use
|
||||
``backend`` instead.
|
||||
|
||||
Profitbricks Cloud Updated Dependency
|
||||
-------------------------------------
|
||||
=====================================
|
||||
|
||||
The minimum version of the `profitbrick` python package for the `profitbricks`
|
||||
The minimum version of the ``profitbrick`` python package for the ``profitbricks``
|
||||
cloud driver has changed from 3.0.0 to 3.1.0.
|
||||
|
||||
Azure Cloud Updated Dependency
|
||||
------------------------------
|
||||
|
||||
The azure sdk used for the ``azurearm`` cloud driver now depends on ``azure-cli>=2.0.12``
|
||||
|
||||
Module Deprecations
|
||||
-------------------
|
||||
===================
|
||||
|
||||
The ``blockdev`` execution module has been removed. Its functions were merged
|
||||
with the ``disk`` module. Please use the ``disk`` execution module instead.
|
||||
|
|
@ -154,7 +939,7 @@ The ``win_service`` module had the following changes:
|
|||
``service_type`` instead.
|
||||
|
||||
Runner Deprecations
|
||||
-------------------
|
||||
===================
|
||||
|
||||
The ``manage`` runner had the following changes:
|
||||
|
||||
|
|
@ -162,7 +947,7 @@ The ``manage`` runner had the following changes:
|
|||
use ``salt-ssh`` roster entries for the host instead.
|
||||
|
||||
State Deprecations
|
||||
------------------
|
||||
==================
|
||||
|
||||
The ``archive`` state had the following changes:
|
||||
|
||||
|
|
@ -185,15 +970,34 @@ The ``file`` state had the following changes:
|
|||
- The ``show_diff`` option was removed. Please use ``show_changes`` instead.
|
||||
|
||||
Grain Deprecations
|
||||
------------------
|
||||
==================
|
||||
|
||||
For ``smartos`` some grains have been deprecated. These grains will be removed in Neon.
|
||||
|
||||
- The ``hypervisor_uuid`` has been replaced with ``mdata:sdc:server_uuid`` grain.
|
||||
- The ``datacenter`` has been replaced with ``mdata:sdc:datacenter_name`` grain.
|
||||
|
||||
Minion Blackout
|
||||
---------------
|
||||
|
||||
During a blackout, minions will not execute any remote execution commands,
|
||||
except for :mod:`saltutil.refresh_pillar <salt.modules.saltutil.refresh_pillar>`.
|
||||
Previously, support was added so that blackouts are enabled using a special
|
||||
pillar key, ``minion_blackout`` set to ``True`` and an optional pillar key
|
||||
``minion_blackout_whitelist`` to specify additional functions that are permitted
|
||||
during blackout. This release adds support for using this feature in the grains
|
||||
as well, by using special grains keys ``minion_blackout`` and
|
||||
``minion_blackout_whitelist``.
|
||||
|
||||
Pillar Deprecations
|
||||
-------------------
|
||||
|
||||
The legacy configuration for ``git_pillar`` has been removed. Please use the new
|
||||
configuration for ``git_pillar``, which is documented in the external pillar module
|
||||
for :mod:`git_pillar <salt.pillar.git_pillar>`.
|
||||
|
||||
Utils Deprecations
|
||||
------------------
|
||||
==================
|
||||
|
||||
The ``salt.utils.cloud.py`` file had the following change:
|
||||
|
||||
|
|
@ -201,8 +1005,12 @@ The ``salt.utils.cloud.py`` file had the following change:
|
|||
optional.
|
||||
|
||||
Other Miscellaneous Deprecations
|
||||
--------------------------------
|
||||
================================
|
||||
|
||||
The ``version.py`` file had the following changes:
|
||||
|
||||
- The ``rc_info`` function was removed. Please use ``pre_info`` instead.
|
||||
|
||||
Warnings for moving away from the ``env`` option were removed. ``saltenv`` should be
|
||||
used instead. The removal of these warnings does not have a behavior change. Only
|
||||
the warning text was removed.
|
||||
|
|
|
|||
|
|
@ -166,13 +166,15 @@ Ubuntu 14.04 LTS and Debian Wheezy (7.x) also have a compatible version packaged
|
|||
|
||||
# apt-get install python-git
|
||||
|
||||
If your master is running an older version (such as Ubuntu 12.04 LTS or Debian
|
||||
Squeeze), then you will need to install GitPython using either pip_ or
|
||||
easy_install (it is recommended to use pip). Version 0.3.2.RC1 is now marked as
|
||||
the stable release in PyPI, so it should be a simple matter of running ``pip
|
||||
install GitPython`` (or ``easy_install GitPython``) as root.
|
||||
GitPython_ requires the ``git`` CLI utility to work. If installed from a system
|
||||
package, then git should already be installed, but if installed via pip_ then
|
||||
it may still be necessary to install git separately. For MacOS users,
|
||||
GitPython_ comes bundled in with the Salt installer, but git must still be
|
||||
installed for it to work properly. Git can be installed in several ways,
|
||||
including by installing XCode_.
|
||||
|
||||
.. _`pip`: http://www.pip-installer.org/
|
||||
.. _pip: http://www.pip-installer.org/
|
||||
.. _XCode: https://developer.apple.com/xcode/
|
||||
|
||||
.. warning::
|
||||
|
||||
|
|
@ -1108,15 +1110,8 @@ Using Git as an External Pillar Source
|
|||
The git external pillar (a.k.a. git_pillar) has been rewritten for the 2015.8.0
|
||||
release. This rewrite brings with it pygit2_ support (allowing for access to
|
||||
authenticated repositories), as well as more granular support for per-remote
|
||||
configuration.
|
||||
|
||||
To make use of the new features, changes to the git ext_pillar configuration
|
||||
must be made. The new configuration schema is detailed :ref:`here
|
||||
<git-pillar-2015-8-0-and-later>`.
|
||||
|
||||
For Salt releases before 2015.8.0, click :ref:`here <git-pillar-pre-2015-8-0>`
|
||||
for documentation.
|
||||
|
||||
configuration. This configuration schema is detailed :ref:`here
|
||||
<git-pillar-configuration>`.
|
||||
|
||||
.. _faq-gitfs-bug:
|
||||
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ To pass through a file that contains jinja + yaml templating (the default):
|
|||
method='POST',
|
||||
data_file='/srv/salt/somefile.jinja',
|
||||
data_render=True,
|
||||
template_data={'key1': 'value1', 'key2': 'value2'}
|
||||
template_dict={'key1': 'value1', 'key2': 'value2'}
|
||||
)
|
||||
|
||||
To pass through a file that contains mako templating:
|
||||
|
|
@ -123,7 +123,7 @@ To pass through a file that contains mako templating:
|
|||
data_file='/srv/salt/somefile.mako',
|
||||
data_render=True,
|
||||
data_renderer='mako',
|
||||
template_data={'key1': 'value1', 'key2': 'value2'}
|
||||
template_dict={'key1': 'value1', 'key2': 'value2'}
|
||||
)
|
||||
|
||||
Because this function uses Salt's own rendering system, any Salt renderer can
|
||||
|
|
@ -140,7 +140,7 @@ However, this can be changed to ``master`` if necessary.
|
|||
method='POST',
|
||||
data_file='/srv/salt/somefile.jinja',
|
||||
data_render=True,
|
||||
template_data={'key1': 'value1', 'key2': 'value2'},
|
||||
template_dict={'key1': 'value1', 'key2': 'value2'},
|
||||
opts=__opts__
|
||||
)
|
||||
|
||||
|
|
@ -149,7 +149,7 @@ However, this can be changed to ``master`` if necessary.
|
|||
method='POST',
|
||||
data_file='/srv/salt/somefile.jinja',
|
||||
data_render=True,
|
||||
template_data={'key1': 'value1', 'key2': 'value2'},
|
||||
template_dict={'key1': 'value1', 'key2': 'value2'},
|
||||
node='master'
|
||||
)
|
||||
|
||||
|
|
@ -170,11 +170,11 @@ a Python dict.
|
|||
header_file='/srv/salt/headers.jinja',
|
||||
header_render=True,
|
||||
header_renderer='jinja',
|
||||
template_data={'key1': 'value1', 'key2': 'value2'}
|
||||
template_dict={'key1': 'value1', 'key2': 'value2'}
|
||||
)
|
||||
|
||||
Because much of the data that would be templated between headers and data may be
|
||||
the same, the ``template_data`` is the same for both. Correcting possible
|
||||
the same, the ``template_dict`` is the same for both. Correcting possible
|
||||
variable name collisions is up to the user.
|
||||
|
||||
Authentication
|
||||
|
|
|
|||
|
|
@ -28,9 +28,8 @@ Tutorials Index
|
|||
* :ref:`States tutorial, part 3 - Templating, Includes, Extends <tutorial-states-part-3>`
|
||||
* :ref:`States tutorial, part 4 <tutorial-states-part-4>`
|
||||
* :ref:`How to Convert Jinja Logic to an Execution Module <tutorial-jinja_to_execution-module>`
|
||||
* :ref:`Using Salt with Stormpath <tutorial-stormpath>`
|
||||
* :ref:`Syslog-ng usage <syslog-ng-sate-usage>`
|
||||
* :ref:`The macOS (Maverick) Developer Step By Step Guide To Salt Installation <tutorial-macos-walk-through>`
|
||||
* :ref:`SaltStack Walk-through <tutorial-salt-walk-through>`
|
||||
* :ref:`Writing Salt Tests <tutorial-salt-testing>`
|
||||
* :ref:`Multi-cloud orchestration with Apache Libcloud <tutorial-libcloud>`
|
||||
* :ref:`Multi-cloud orchestration with Apache Libcloud <tutorial-libcloud>`
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Using Apache Libcloud for declarative and procedural multi-cloud orchestration
|
|||
|
||||
Apache Libcloud is a Python library which hides differences between different cloud provider APIs and allows
|
||||
you to manage different cloud resources through a unified and easy to use API. Apache Libcloud supports over
|
||||
60 cloud platforms, including Amazon, Microsoft Azure, Digital Ocean, Google Cloud Platform and OpenStack.
|
||||
60 cloud platforms, including Amazon, Microsoft Azure, DigitalOcean, Google Cloud Platform and OpenStack.
|
||||
|
||||
Execution and state modules are available for Compute, DNS, Storage and Load Balancer drivers from Apache Libcloud in
|
||||
SaltStack.
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ The default location for the pillar is in /srv/pillar.
|
|||
|
||||
.. note::
|
||||
|
||||
The pillar location can be configured via the `pillar_roots` option inside
|
||||
The pillar location can be configured via the ``pillar_roots`` option inside
|
||||
the master configuration file. It must not be in a subdirectory of the state
|
||||
tree or file_roots. If the pillar is under file_roots, any pillar targeting
|
||||
can be bypassed by minions.
|
||||
|
|
@ -242,7 +242,7 @@ set in the minion's pillar, then the default of ``httpd`` will be used.
|
|||
.. note::
|
||||
|
||||
Under the hood, pillar is just a Python dict, so Python dict methods such
|
||||
as `get` and `items` can be used.
|
||||
as ``get`` and ``items`` can be used.
|
||||
|
||||
Pillar Makes Simple States Grow Easily
|
||||
======================================
|
||||
|
|
@ -303,6 +303,18 @@ Where the vimrc source location can now be changed via pillar:
|
|||
|
||||
Ensuring that the right vimrc is sent out to the correct minions.
|
||||
|
||||
The pillar top file must include a reference to the new sls pillar file:
|
||||
|
||||
``/srv/pillar/top.sls``:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
base:
|
||||
'*':
|
||||
- pkg
|
||||
- edit.vim
|
||||
|
||||
|
||||
Setting Pillar Data on the Command Line
|
||||
=======================================
|
||||
|
||||
|
|
|
|||
|
|
@ -1,198 +0,0 @@
|
|||
.. _tutorial-stormpath:
|
||||
|
||||
=========================
|
||||
Using Salt with Stormpath
|
||||
=========================
|
||||
|
||||
`Stormpath <https://stormpath.com/>`_ is a user management and authentication
|
||||
service. This tutorial covers using SaltStack to manage and take advantage of
|
||||
Stormpath's features.
|
||||
|
||||
External Authentication
|
||||
-----------------------
|
||||
Stormpath can be used for Salt's external authentication system. In order to do
|
||||
this, the master should be configured with an ``apiid``, ``apikey``, and the ID
|
||||
of the ``application`` that is associated with the users to be authenticated:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
stormpath:
|
||||
apiid: 367DFSF4FRJ8767FSF4G34FGH
|
||||
apikey: FEFREF43t3FEFRe/f323fwer4FWF3445gferWRWEer1
|
||||
application: 786786FREFrefreg435fr1
|
||||
|
||||
.. note::
|
||||
These values can be found in the `Stormpath dashboard
|
||||
<https://api.stormpath.com/ui2/index.html#/>`_`.
|
||||
|
||||
Users that are to be authenticated should be set up under the ``stormpath``
|
||||
dict under ``external_auth``:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
external_auth:
|
||||
stormpath:
|
||||
larry:
|
||||
- .*
|
||||
- '@runner'
|
||||
- '@wheel'
|
||||
|
||||
Keep in mind that while Stormpath defaults the username associated with the
|
||||
account to the email address, it is better to use a username without an ``@``
|
||||
sign in it.
|
||||
|
||||
|
||||
Configuring Stormpath Modules
|
||||
-----------------------------
|
||||
Stormpath accounts can be managed via either an execution or state module. In
|
||||
order to use either, a minion must be configured with an API ID and key.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
stormpath:
|
||||
apiid: 367DFSF4FRJ8767FSF4G34FGH
|
||||
apikey: FEFREF43t3FEFRe/f323fwer4FWF3445gferWRWEer1
|
||||
directory: efreg435fr1786786FREFr
|
||||
application: 786786FREFrefreg435fr1
|
||||
|
||||
Some functions in the ``stormpath`` modules can make use of other options. The
|
||||
following options are also available.
|
||||
|
||||
directory
|
||||
`````````
|
||||
The ID of the directory that is to be used with this minion. Many functions
|
||||
require an ID to be specified to do their work. However, if the ID of a
|
||||
``directory`` is specified, then Salt can often look up the resource in
|
||||
question.
|
||||
|
||||
application
|
||||
```````````
|
||||
The ID of the application that is to be used with this minion. Many functions
|
||||
require an ID to be specified to do their work. However, if the ID of a
|
||||
``application`` is specified, then Salt can often look up the resource in
|
||||
question.
|
||||
|
||||
|
||||
Managing Stormpath Accounts
|
||||
---------------------------
|
||||
With the ``stormpath`` configuration in place, Salt can be used to configure
|
||||
accounts (which may be thought of as users) on the Stormpath service. The
|
||||
following functions are available.
|
||||
|
||||
stormpath.create_account
|
||||
````````````````````````
|
||||
Create an account on the Stormpath service. This requires a ``directory_id`` as
|
||||
the first argument; it will not be retrieved from the minion configuration. An
|
||||
``email`` address, ``password``, first name (``givenName``) and last name
|
||||
(``surname``) are also required. For the full list of other parameters that may
|
||||
be specified, see:
|
||||
|
||||
http://docs.stormpath.com/rest/product-guide/#account-resource
|
||||
|
||||
When executed with no errors, this function will return the information about
|
||||
the account, from Stormpath.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt myminion stormpath.create_account <directory_id> shemp@example.com letmein Shemp Howard
|
||||
|
||||
|
||||
stormpath.list_accounts
|
||||
```````````````````````
|
||||
Show all accounts on the Stormpath service. This will return all accounts,
|
||||
regardless of directory, application, or group.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt myminion stormpath.list_accounts
|
||||
'''
|
||||
|
||||
stormpath.show_account
|
||||
``````````````````````
|
||||
Show the details for a specific Stormpath account. An ``account_id`` is normally
|
||||
required. However, if am ``email`` is provided instead, along with either a
|
||||
``directory_id``, ``application_id``, or ``group_id``, then Salt will search the
|
||||
specified resource to try and locate the ``account_id``.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt myminion stormpath.show_account <account_id>
|
||||
salt myminion stormpath.show_account email=<email> directory_id=<directory_id>
|
||||
|
||||
|
||||
stormpath.update_account
|
||||
````````````````````````
|
||||
Update one or more items for this account. Specifying an empty value will clear
|
||||
it for that account. This function may be used in one of two ways. In order to
|
||||
update only one key/value pair, specify them in order:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt myminion stormpath.update_account <account_id> givenName shemp
|
||||
salt myminion stormpath.update_account <account_id> middleName ''
|
||||
|
||||
In order to specify multiple items, they need to be passed in as a dict. From
|
||||
the command line, it is best to do this as a JSON string:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt myminion stormpath.update_account <account_id> items='{"givenName": "Shemp"}
|
||||
salt myminion stormpath.update_account <account_id> items='{"middlename": ""}
|
||||
|
||||
When executed with no errors, this function will return the information about
|
||||
the account, from Stormpath.
|
||||
|
||||
|
||||
stormpath.delete_account
|
||||
````````````````````````
|
||||
Delete an account from Stormpath.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt myminion stormpath.delete_account <account_id>
|
||||
|
||||
|
||||
stormpath.list_directories
|
||||
``````````````````````````
|
||||
Show all directories associated with this tenant.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt myminion stormpath.list_directories
|
||||
|
||||
|
||||
Using Stormpath States
|
||||
----------------------
|
||||
Stormpath resources may be managed using the state system. The following states
|
||||
are available.
|
||||
|
||||
stormpath_account.present
|
||||
`````````````````````````
|
||||
Ensure that an account exists on the Stormpath service. All options that are
|
||||
available with the ``stormpath.create_account`` function are available here.
|
||||
If an account needs to be created, then this function will require the same
|
||||
fields that ``stormpath.create_account`` requires, including the ``password``.
|
||||
However, if a password changes for an existing account, it will NOT be updated
|
||||
by this state.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
curly@example.com:
|
||||
stormpath_account.present:
|
||||
- directory_id: efreg435fr1786786FREFr
|
||||
- password: badpass
|
||||
- firstName: Curly
|
||||
- surname: Howard
|
||||
- nickname: curly
|
||||
|
||||
It is advisable to always set a ``nickname`` that is not also an email address,
|
||||
so that it can be used by Salt's external authentication module.
|
||||
|
||||
stormpath_account.absent
|
||||
````````````````````````
|
||||
Ensure that an account does not exist on Stormpath. As with
|
||||
``stormpath_account.present``, the ``name`` supplied to this state is the
|
||||
``email`` address associated with this account. Salt will use this, with or
|
||||
without the ``directory`` ID that is configured for the minion. However, lookups
|
||||
will be much faster with a directory ID specified.
|
||||
|
||||
|
|
@ -81,14 +81,18 @@ the ``foo`` utility module with a ``__virtual__`` function.
|
|||
def bar():
|
||||
return 'baz'
|
||||
|
||||
.. versionadded:: Oxygen
|
||||
Instantiating objects from classes declared in util modules works with
|
||||
Master side modules, such as Runners, Outputters, etc.
|
||||
|
||||
Also you could even write your utility modules in object oriented fashion:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
# -*- coding: utf-8 -*-
|
||||
'''
|
||||
My utils module
|
||||
---------------
|
||||
My OOP-style utils module
|
||||
-------------------------
|
||||
|
||||
This module contains common functions for use in my other custom types.
|
||||
'''
|
||||
|
|
|
|||
|
|
@ -481,11 +481,17 @@ Alternatively the ``uninstaller`` can also simply repeat the URL of the msi file
|
|||
:param bool allusers: This parameter is specific to `.msi` installations. It
|
||||
tells `msiexec` to install the software for all users. The default is True.
|
||||
|
||||
:param bool cache_dir: If true, the entire directory where the installer resides
|
||||
will be recursively cached. This is useful for installers that depend on
|
||||
other files in the same directory for installation.
|
||||
:param bool cache_dir: If true when installer URL begins with salt://, the
|
||||
entire directory where the installer resides will be recursively cached.
|
||||
This is useful for installers that depend on other files in the same
|
||||
directory for installation.
|
||||
|
||||
.. note:: Only applies to salt: installer URLs.
|
||||
:param str cache_file:
|
||||
When installer URL begins with salt://, this indicates single file to copy
|
||||
down for use with the installer. Copied to the same location as the
|
||||
installer. Use this over ``cache_dir`` if there are many files in the
|
||||
directory and you only need a specific file and don't want to cache
|
||||
additional files that may reside in the installer directory.
|
||||
|
||||
Here's an example for a software package that has dependent files:
|
||||
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Reference in a new issue