mirror of
https://github.com/valitydev/salt.git
synced 2024-11-07 00:55:19 +00:00
Merge branch 'develop' into dev/iepopr/add_salt-api_windows
Signed-off-by: Rares POP <rares.pop@ni.com>
This commit is contained in:
Rares POP
commit
895d8cee5c
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
|
||||
# 690 is approximately 1 year and 11 months
|
||||
daysUntilStale: 690
|
||||
# 680 is approximately 1 year and 10 months
|
||||
daysUntilStale: 680
|
||||
|
||||
# Number of days of inactivity before a stale issue is closed
|
||||
daysUntilClose: 7
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
#!/usr/bin/env python
|
||||
# -*- coding: utf-8 -*-
|
||||
'''
|
||||
:codeauthor: :email:`Pedro Algarvio (pedro@algarvio.me)`
|
||||
:codeauthor: Pedro Algarvio (pedro@algarvio.me)
|
||||
|
||||
|
||||
compile-translation-catalogs
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
#!/usr/bin/env python
|
||||
# -*- coding: utf-8 -*-
|
||||
'''
|
||||
:codeauthor: :email:`Pedro Algarvio (pedro@algarvio.me)`
|
||||
:codeauthor: Pedro Algarvio (pedro@algarvio.me)
|
||||
|
||||
|
||||
download-translation-catalog
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
#!/usr/bin/env python
|
||||
# -*- coding: utf-8 -*-
|
||||
'''
|
||||
:codeauthor: :email:`Pedro Algarvio (pedro@algarvio.me)`
|
||||
:codeauthor: Pedro Algarvio (pedro@algarvio.me)
|
||||
|
||||
|
||||
setup-transifex-config
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
#!/usr/bin/env python
|
||||
# -*- coding: utf-8 -*-
|
||||
'''
|
||||
:codeauthor: :email:`Pedro Algarvio (pedro@algarvio.me)`
|
||||
:codeauthor: Pedro Algarvio (pedro@algarvio.me)
|
||||
|
||||
|
||||
update-transifex-source-translations
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# -*- coding: utf-8 -*-
|
||||
'''
|
||||
:codeauthor: :email:`Pedro Algarvio (pedro@algarvio.me)`
|
||||
:codeauthor: Pedro Algarvio (pedro@algarvio.me)
|
||||
|
||||
|
||||
saltautodoc.py
|
||||
|
||||
20
doc/conf.py
20
doc/conf.py
@ -6,6 +6,7 @@ Sphinx documentation for Salt
|
||||
import functools
|
||||
import sys
|
||||
import os
|
||||
import re
|
||||
import types
|
||||
import time
|
||||
|
||||
@ -106,6 +107,7 @@ MOCK_MODULES = [
|
||||
|
||||
'tornado',
|
||||
'tornado.concurrent',
|
||||
'tornado.escape',
|
||||
'tornado.gen',
|
||||
'tornado.httpclient',
|
||||
'tornado.httpserver',
|
||||
@ -137,8 +139,8 @@ MOCK_MODULES = [
|
||||
'pymongo',
|
||||
'rabbitmq_server',
|
||||
'redis',
|
||||
'requests',
|
||||
'requests.exceptions',
|
||||
#'requests',
|
||||
#'requests.exceptions',
|
||||
'rpm',
|
||||
'rpmUtils',
|
||||
'rpmUtils.arch',
|
||||
@ -150,6 +152,7 @@ MOCK_MODULES = [
|
||||
'ntsecuritycon',
|
||||
'napalm',
|
||||
'dson',
|
||||
'hjson',
|
||||
'jnpr',
|
||||
'json',
|
||||
'lxml',
|
||||
@ -237,8 +240,7 @@ formulas_dir = os.path.join(os.pardir, docs_basepath, 'formulas')
|
||||
|
||||
# ----- Intersphinx Settings ------------------------------------------------>
|
||||
intersphinx_mapping = {
|
||||
'python2': ('http://docs.python.org/2', None),
|
||||
'python3': ('http://docs.python.org/3', None)
|
||||
'python': ('https://docs.python.org/3', None)
|
||||
}
|
||||
# <---- Intersphinx Settings -------------------------------------------------
|
||||
|
||||
@ -316,6 +318,9 @@ modindex_common_prefix = ['salt.']
|
||||
|
||||
autosummary_generate = True
|
||||
|
||||
# strip git rev as there won't necessarily be a release based on it
|
||||
stripped_release = re.sub(r'-\d+-g[0-9a-f]+$', '', release)
|
||||
|
||||
# Define a substitution for linking to the latest release tarball
|
||||
rst_prolog = """\
|
||||
.. |current_release_doc| replace:: :doc:`/topics/releases/{release}`
|
||||
@ -352,14 +357,13 @@ rst_prolog = """\
|
||||
<p>x86_64: <a href="https://repo.saltstack.com/osx/salt-{release}-py3-x86_64.pkg"><strong>salt-{release}-py3-x86_64.pkg</strong></a>
|
||||
| <a href="https://repo.saltstack.com/osx/salt-{release}-py3-x86_64.pkg.md5"><strong>md5</strong></a></p>
|
||||
|
||||
""".format(release=release)
|
||||
""".format(release=stripped_release)
|
||||
|
||||
# A shortcut for linking to tickets on the GitHub issue tracker
|
||||
extlinks = {
|
||||
'blob': ('https://github.com/saltstack/salt/blob/%s/%%s' % 'develop', None),
|
||||
'download': ('https://cloud.github.com/downloads/saltstack/salt/%s', None),
|
||||
'issue': ('https://github.com/saltstack/salt/issues/%s', 'issue '),
|
||||
'pull': ('https://github.com/saltstack/salt/pull/%s', 'PR '),
|
||||
'issue': ('https://github.com/saltstack/salt/issues/%s', 'issue #'),
|
||||
'pull': ('https://github.com/saltstack/salt/pull/%s', 'PR #'),
|
||||
'formula_url': ('https://github.com/saltstack-formulas/%s', ''),
|
||||
}
|
||||
|
||||
|
||||
@ -7,6 +7,7 @@ Salt Table of Contents
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
topics/index
|
||||
topics/installation/index
|
||||
topics/configuration/index
|
||||
topics/using_salt
|
||||
@ -15,12 +16,16 @@ Salt Table of Contents
|
||||
topics/utils/index
|
||||
topics/event/index
|
||||
topics/orchestrate/index
|
||||
topics/solaris/index
|
||||
topics/ssh/index
|
||||
topics/thorium/index
|
||||
topics/cloud/index
|
||||
topics/proxyminion/index
|
||||
topics/network_automation/index
|
||||
topics/virt/index
|
||||
ref/cli/index
|
||||
ref/pillar/index
|
||||
ref/tops/index
|
||||
ref/index
|
||||
topics/api
|
||||
topics/topology/index
|
||||
@ -30,3 +35,4 @@ Salt Table of Contents
|
||||
topics/development/index
|
||||
topics/releases/index
|
||||
topics/venafi/index
|
||||
glossary
|
||||
|
||||
BIN
doc/favicon.ico
Normal file
BIN
doc/favicon.ico
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.1 KiB |
@ -1,5 +1,5 @@
|
||||
salt.beacons.sensehat module
|
||||
=======================
|
||||
============================
|
||||
|
||||
.. automodule:: salt.beacons.sensehat
|
||||
:members:
|
||||
|
||||
6
doc/ref/cache/all/index.rst
vendored
6
doc/ref/cache/all/index.rst
vendored
@ -1,7 +1,7 @@
|
||||
.. _all-salt.cache:
|
||||
|
||||
=============
|
||||
cache modules
|
||||
Cache Modules
|
||||
=============
|
||||
|
||||
.. currentmodule:: salt.cache
|
||||
@ -10,6 +10,8 @@ cache modules
|
||||
:toctree:
|
||||
:template: autosummary.rst.tmpl
|
||||
|
||||
localfs
|
||||
consul
|
||||
etcd_cache
|
||||
localfs
|
||||
mysql_cache
|
||||
redis_cache
|
||||
|
||||
4
doc/ref/cache/all/salt.cache.consul.rst
vendored
4
doc/ref/cache/all/salt.cache.consul.rst
vendored
@ -1,5 +1,5 @@
|
||||
salt.cache.consul module
|
||||
========================
|
||||
salt.cache.consul
|
||||
=================
|
||||
|
||||
.. automodule:: salt.cache.consul
|
||||
:members:
|
||||
|
||||
4
doc/ref/cache/all/salt.cache.etcd_cache.rst
vendored
4
doc/ref/cache/all/salt.cache.etcd_cache.rst
vendored
@ -1,5 +1,5 @@
|
||||
salt.cache.etcd_cache module
|
||||
=============================
|
||||
salt.cache.etcd_cache
|
||||
=====================
|
||||
|
||||
.. automodule:: salt.cache.etcd_cache
|
||||
:members:
|
||||
|
||||
4
doc/ref/cache/all/salt.cache.localfs.rst
vendored
4
doc/ref/cache/all/salt.cache.localfs.rst
vendored
@ -1,5 +1,5 @@
|
||||
salt.cache.localfs module
|
||||
=========================
|
||||
salt.cache.localfs
|
||||
==================
|
||||
|
||||
.. automodule:: salt.cache.localfs
|
||||
:members:
|
||||
|
||||
4
doc/ref/cache/all/salt.cache.mysql_cache.rst
vendored
4
doc/ref/cache/all/salt.cache.mysql_cache.rst
vendored
@ -1,5 +1,5 @@
|
||||
salt.cache.mysql_cache module
|
||||
=============================
|
||||
salt.cache.mysql_cache
|
||||
======================
|
||||
|
||||
.. automodule:: salt.cache.mysql_cache
|
||||
:members:
|
||||
|
||||
4
doc/ref/cache/all/salt.cache.redis_cache.rst
vendored
4
doc/ref/cache/all/salt.cache.redis_cache.rst
vendored
@ -1,5 +1,5 @@
|
||||
salt.cache.redis_cache module
|
||||
=============================
|
||||
salt.cache.redis_cache
|
||||
======================
|
||||
|
||||
.. automodule:: salt.cache.redis_cache
|
||||
:members:
|
||||
|
||||
@ -74,6 +74,12 @@ salt-syndic
|
||||
|
||||
salt-syndic
|
||||
|
||||
salt-unity
|
||||
==========
|
||||
.. toctree::
|
||||
|
||||
salt-unity
|
||||
|
||||
salt-api
|
||||
========
|
||||
.. toctree::
|
||||
|
||||
@ -46,14 +46,6 @@ Options
|
||||
Instead of waiting for the job to run on minions only print the job id of
|
||||
the started execution and complete.
|
||||
|
||||
.. option:: --state-output=STATE_OUTPUT
|
||||
|
||||
.. versionadded:: 0.17
|
||||
|
||||
Override the configured ``state_output`` value for minion output. One of
|
||||
``full``, ``terse``, ``mixed``, ``changes`` or ``filter``. Default:
|
||||
``full``.
|
||||
|
||||
.. option:: --subset=SUBSET
|
||||
|
||||
Execute the routine on a random subset of the targeted minions. The
|
||||
|
||||
@ -72,6 +72,7 @@ Each module type has a corresponding loader function.
|
||||
Salt's Client Interfaces
|
||||
========================
|
||||
|
||||
.. _client-interfaces:
|
||||
.. _local-client:
|
||||
|
||||
LocalClient
|
||||
|
||||
@ -23,6 +23,7 @@ cloud modules
|
||||
lxc
|
||||
msazure
|
||||
nova
|
||||
oneandone
|
||||
opennebula
|
||||
openstack
|
||||
parallels
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
===============================
|
||||
========================
|
||||
salt.cloud.clouds.aliyun
|
||||
===============================
|
||||
========================
|
||||
|
||||
.. automodule:: salt.cloud.clouds.aliyun
|
||||
:members:
|
||||
:members:
|
||||
|
||||
@ -1,5 +1,6 @@
|
||||
salt.cloud.clouds.vultrpy module
|
||||
================================
|
||||
=========================
|
||||
salt.cloud.clouds.vultrpy
|
||||
=========================
|
||||
|
||||
.. automodule:: salt.cloud.clouds.vultrpy
|
||||
:members:
|
||||
|
||||
@ -9,7 +9,7 @@ issues you might find along the way.
|
||||
|
||||
If you want to get some more information on the nitty-gritty of salt's logging
|
||||
system, please head over to the :ref:`logging development
|
||||
document<logging-internals>`, if all you're after is salt's logging
|
||||
document <logging-internals>`, if all you're after is salt's logging
|
||||
configurations, please continue reading.
|
||||
|
||||
|
||||
@ -25,10 +25,9 @@ example, setting ``log_level: error`` will log statements at ``error``,
|
||||
``quiet`` level.
|
||||
|
||||
Most of the logging levels are defined by default in Python's logging library
|
||||
and can be found in the official `Python documentation
|
||||
<https://docs.python.org/library/logging.html#levels>`_. Salt uses some more
|
||||
levels in addition to the standard levels. All levels available in salt are
|
||||
shown in the table below.
|
||||
and can be found in the official :ref:`Python documentation <python:levels>`.
|
||||
Salt uses some more levels in addition to the standard levels. All levels
|
||||
available in salt are shown in the table below.
|
||||
|
||||
.. note::
|
||||
|
||||
@ -74,11 +73,14 @@ The log records can be sent to a regular file, local path name, or network
|
||||
location. Remote logging works best when configured to use rsyslogd(8) (e.g.:
|
||||
``file:///dev/log``), with rsyslogd(8) configured for network logging. The
|
||||
format for remote addresses is:
|
||||
``<file|udp|tcp>://<host|socketpath>:<port-if-required>/<log-facility>``. Where
|
||||
``log-facility`` is the symbolic name of a syslog facility as defined in the
|
||||
:ref:`SysLogHandler documentation
|
||||
<python2:logging.handlers.SysLogHandler.encodePriority>` . It defaults to
|
||||
``LOG_USER``.
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
<file|udp|tcp>://<host|socketpath>:<port-if-required>/<log-facility>
|
||||
|
||||
Where ``log-facility`` is the symbolic name of a syslog facility as defined in
|
||||
the :py:meth:`SysLogHandler documentation
|
||||
<logging.handlers.SysLogHandler.encodePriority>`. It defaults to ``LOG_USER``.
|
||||
|
||||
Default: Dependent of the binary being executed, for example, for
|
||||
``salt-master``, ``/var/log/salt/master``.
|
||||
@ -148,7 +150,7 @@ The level of messages to send to the log file. One of ``all``, ``garbage``,
|
||||
Default: ``%H:%M:%S``
|
||||
|
||||
The date and time format used in console log messages. Allowed date/time
|
||||
formatting can be seen on :func:`time.strftime <python2:time.strftime>`.
|
||||
formatting matches those used in :py:func:`time.strftime`.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -162,7 +164,7 @@ formatting can be seen on :func:`time.strftime <python2:time.strftime>`.
|
||||
Default: ``%Y-%m-%d %H:%M:%S``
|
||||
|
||||
The date and time format used in log file messages. Allowed date/time
|
||||
formatting can be seen on :func:`time.strftime <python2:time.strftime>`.
|
||||
formatting matches those used in :py:func:`time.strftime`.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -176,8 +178,8 @@ formatting can be seen on :func:`time.strftime <python2:time.strftime>`.
|
||||
Default: ``[%(levelname)-8s] %(message)s``
|
||||
|
||||
The format of the console logging messages. All standard python logging
|
||||
:ref:`LogRecord attributes <python2:logrecord-attributes>` can be used. Salt
|
||||
also provides these custom LogRecord attributes to colorize console log output:
|
||||
:py:class:`~logging.LogRecord` attributes can be used. Salt also provides these
|
||||
custom LogRecord attributes to colorize console log output:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
@ -204,9 +206,9 @@ also provides these custom LogRecord attributes to colorize console log output:
|
||||
Default: ``%(asctime)s,%(msecs)03d [%(name)-17s][%(levelname)-8s] %(message)s``
|
||||
|
||||
The format of the log file logging messages. All standard python logging
|
||||
:ref:`LogRecord attributes <python2:logrecord-attributes>` can be used. Salt
|
||||
also provides these custom LogRecord attributes that include padding and
|
||||
enclosing brackets ``[`` and ``]``:
|
||||
:py:class:`~logging.LogRecord` attributes can be used. Salt also provides
|
||||
these custom LogRecord attributes that include padding and enclosing brackets
|
||||
``[`` and ``]``:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
|
||||
@ -428,7 +428,7 @@ to False.
|
||||
.. conf_master:: color_theme
|
||||
|
||||
``color_theme``
|
||||
---------
|
||||
---------------
|
||||
|
||||
Default: ``""``
|
||||
|
||||
@ -728,31 +728,6 @@ master event bus. The value is expressed in bytes.
|
||||
|
||||
max_event_size: 1048576
|
||||
|
||||
.. conf_master:: ping_on_rotate
|
||||
|
||||
``ping_on_rotate``
|
||||
------------------
|
||||
|
||||
.. versionadded:: 2014.7.0
|
||||
|
||||
Default: ``False``
|
||||
|
||||
By default, the master AES key rotates every 24 hours. The next command
|
||||
following a key rotation will trigger a key refresh from the minion which may
|
||||
result in minions which do not respond to the first command after a key refresh.
|
||||
|
||||
To tell the master to ping all minions immediately after an AES key refresh, set
|
||||
ping_on_rotate to ``True``. This should mitigate the issue where a minion does not
|
||||
appear to initially respond after a key is rotated.
|
||||
|
||||
Note that ping_on_rotate may cause high load on the master immediately after
|
||||
the key rotation event as minions reconnect. Consider this carefully if this
|
||||
salt master is managing a large number of minions.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
ping_on_rotate: False
|
||||
|
||||
.. conf_master:: master_job_cache
|
||||
|
||||
``master_job_cache``
|
||||
@ -840,6 +815,8 @@ that connect to a master via localhost.
|
||||
``ping_on_rotate``
|
||||
------------------
|
||||
|
||||
.. versionadded:: 2014.7.0
|
||||
|
||||
Default: ``False``
|
||||
|
||||
By default, the master AES key rotates every 24 hours. The next command
|
||||
@ -850,9 +827,9 @@ To tell the master to ping all minions immediately after an AES key refresh,
|
||||
set ``ping_on_rotate`` to ``True``. This should mitigate the issue where a
|
||||
minion does not appear to initially respond after a key is rotated.
|
||||
|
||||
Note that ping_on_rotate may cause high load on the master immediately after
|
||||
the key rotation event as minions reconnect. Consider this carefully if this
|
||||
salt master is managing a large number of minions.
|
||||
Note that enabling this may cause high load on the master immediately after the
|
||||
key rotation event as minions reconnect. Consider this carefully if this salt
|
||||
master is managing a large number of minions.
|
||||
|
||||
If disabled, it is recommended to handle this event by listening for the
|
||||
``aes_key_rotate`` event with the ``key`` tag and acting appropriately.
|
||||
@ -872,8 +849,7 @@ Changes the underlying transport layer. ZeroMQ is the recommended transport
|
||||
while additional transport layers are under development. Supported values are
|
||||
``zeromq``, ``raet`` (experimental), and ``tcp`` (experimental). This setting has
|
||||
a significant impact on performance and should not be changed unless you know
|
||||
what you are doing! Transports are explained in :ref:`Salt Transports
|
||||
<transports>`.
|
||||
what you are doing!
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -886,10 +862,10 @@ what you are doing! Transports are explained in :ref:`Salt Transports
|
||||
|
||||
Default: ``{}``
|
||||
|
||||
(experimental) Starts multiple transports and overrides options for each transport with the provided dictionary
|
||||
This setting has a significant impact on performance and should not be changed unless you know
|
||||
what you are doing! Transports are explained in :ref:`Salt Transports
|
||||
<transports>`. The following example shows how to start a TCP transport alongside a ZMQ transport.
|
||||
(experimental) Starts multiple transports and overrides options for each
|
||||
transport with the provided dictionary This setting has a significant impact on
|
||||
performance and should not be changed unless you know what you are doing! The
|
||||
following example shows how to start a TCP transport alongside a ZMQ transport.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -1031,7 +1007,7 @@ a minion performs an authentication check with the master.
|
||||
.. conf_master:: minion_data_cache_events
|
||||
|
||||
``minion_data_cache_events``
|
||||
--------------------
|
||||
----------------------------
|
||||
|
||||
.. versionadded:: 2017.7.3
|
||||
|
||||
@ -1096,6 +1072,23 @@ Define the default salt-ssh roster module to use
|
||||
|
||||
roster: cache
|
||||
|
||||
.. conf_master:: roster_defaults
|
||||
|
||||
``roster_defaults``
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 2017.7.0
|
||||
|
||||
Default settings which will be inherited by all rosters.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
roster_defaults:
|
||||
user: daniel
|
||||
sudo: True
|
||||
priv: /root/.ssh/id_rsa
|
||||
tty: True
|
||||
|
||||
.. conf_master:: roster_file
|
||||
|
||||
``roster_file``
|
||||
@ -1103,24 +1096,27 @@ Define the default salt-ssh roster module to use
|
||||
|
||||
Default: ``/etc/salt/roster``
|
||||
|
||||
Pass in an alternative location for the salt-ssh `flat` roster file.
|
||||
Pass in an alternative location for the salt-ssh :py:mod:`flat
|
||||
<salt.roster.flat>` roster file.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
roster_file: /root/roster
|
||||
|
||||
.. conf_master:: roster_file
|
||||
.. conf_master:: rosters
|
||||
|
||||
``rosters``
|
||||
---------------
|
||||
-----------
|
||||
|
||||
Default: None
|
||||
Default: ``None``
|
||||
|
||||
Define locations for `flat` roster files so they can be chosen when using Salt API.
|
||||
An administrator can place roster files into these locations.
|
||||
Then when calling Salt API, parameter 'roster_file' should contain a relative path to these locations.
|
||||
That is, "roster_file=/foo/roster" will be resolved as "/etc/salt/roster.d/foo/roster" etc.
|
||||
This feature prevents passing insecure custom rosters through the Salt API.
|
||||
Define locations for :py:mod:`flat <salt.roster.flat>` roster files so they can
|
||||
be chosen when using Salt API. An administrator can place roster files into
|
||||
these locations. Then, when calling Salt API, the :conf_master:`roster_file`
|
||||
parameter should contain a relative path to these locations. That is,
|
||||
``roster_file=/foo/roster`` will be resolved as
|
||||
``/etc/salt/roster.d/foo/roster`` etc. This feature prevents passing insecure
|
||||
custom rosters through the Salt API.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -1144,7 +1140,7 @@ The ssh password to log in with.
|
||||
.. conf_master:: ssh_priv_passwd
|
||||
|
||||
``ssh_priv_passwd``
|
||||
--------------
|
||||
-------------------
|
||||
|
||||
Default: ``''``
|
||||
|
||||
@ -1753,10 +1749,10 @@ constant names without ssl module prefix: ``CERT_REQUIRED`` or ``PROTOCOL_SSLv23
|
||||
certfile: <path_to_certfile>
|
||||
ssl_version: PROTOCOL_TLSv1_2
|
||||
|
||||
.. conf_master:: allow_minion_key_revoke
|
||||
.. conf_master:: preserve_minion_cache
|
||||
|
||||
``allow_minion_key_revoke``
|
||||
---------------------------
|
||||
``preserve_minion_cache``
|
||||
-------------------------
|
||||
|
||||
Default: ``False``
|
||||
|
||||
@ -1785,7 +1781,7 @@ the master will drop the request and the minion's key will remain accepted.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
rotate_aes_key: True
|
||||
allow_minion_key_revoke: False
|
||||
|
||||
|
||||
Master Large Scale Tuning Settings
|
||||
@ -2210,6 +2206,7 @@ Example using line statements and line comments to increase ease of use:
|
||||
If your configuration options are
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
jinja_sls_env:
|
||||
line_statement_prefix: '%'
|
||||
line_comment_prefix: '##'
|
||||
@ -2219,7 +2216,7 @@ as a jinja statement and will interpret anything after a ``##`` as a comment.
|
||||
|
||||
This allows the following more convenient syntax to be used:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
## (this comment will not stay once rendered)
|
||||
# (this comment remains in the rendered template)
|
||||
@ -2233,7 +2230,7 @@ This allows the following more convenient syntax to be used:
|
||||
The following less convenient but equivalent syntax would have to
|
||||
be used if you had not set the line_statement and line_comment options:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
{# (this comment will not stay once rendered) #}
|
||||
# (this comment remains in the rendered template)
|
||||
@ -4367,7 +4364,7 @@ Default: ``['+refs/heads/*:refs/remotes/origin/*', '+refs/tags/*:refs/tags/*']``
|
||||
When fetching from remote repositories, by default Salt will fetch branches and
|
||||
tags. This parameter can be used to override the default and specify
|
||||
alternate refspecs to be fetched. This parameter works similarly to its
|
||||
:ref:`GitFS counterpart <git_pillar-custom-refspecs>`, in that it can be
|
||||
:ref:`GitFS counterpart <gitfs-custom-refspecs>`, in that it can be
|
||||
configured both globally and for individual remotes.
|
||||
|
||||
.. code-block:: yaml
|
||||
@ -4415,12 +4412,14 @@ The pillar_source_merging_strategy option allows you to configure merging
|
||||
strategy between different sources. It accepts 5 values:
|
||||
|
||||
* ``none``:
|
||||
.. versionadded:: 2016.3.4
|
||||
|
||||
It will not do any merging at all and only parse the pillar data from the passed environment and 'base' if no environment was specified.
|
||||
|
||||
.. versionadded:: 2016.3.4
|
||||
|
||||
* ``recurse``:
|
||||
|
||||
it will merge recursively mapping of data. For example, theses 2 sources:
|
||||
It will recursively merge data. For example, theses 2 sources:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -5522,7 +5521,7 @@ Default: ``['+refs/heads/*:refs/remotes/origin/*', '+refs/tags/*:refs/tags/*']``
|
||||
When fetching from remote repositories, by default Salt will fetch branches and
|
||||
tags. This parameter can be used to override the default and specify
|
||||
alternate refspecs to be fetched. This parameter works similarly to its
|
||||
:ref:`GitFS counterpart <winrepo-custom-refspecs>`, in that it can be
|
||||
:ref:`GitFS counterpart <gitfs-custom-refspecs>`, in that it can be
|
||||
configured both globally and for individual remotes.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -346,7 +346,7 @@ option on the Salt master.
|
||||
.. conf_minion:: publish_port
|
||||
|
||||
``publish_port``
|
||||
---------------
|
||||
----------------
|
||||
|
||||
Default: ``4505``
|
||||
|
||||
@ -583,7 +583,7 @@ ids.
|
||||
|
||||
Default: ``True``
|
||||
|
||||
Caches the minion id to a file when the minion's :minion_conf:`id` is not
|
||||
Caches the minion id to a file when the minion's :conf_minion:`id` is not
|
||||
statically defined in the minion config. This setting prevents potential
|
||||
problems when automatic minion id resolution changes, which can cause the
|
||||
minion to lose connection with the master. To turn off minion id caching,
|
||||
@ -645,7 +645,7 @@ This directory may contain sensitive data and should be protected accordingly.
|
||||
.. conf_master:: color_theme
|
||||
|
||||
``color_theme``
|
||||
---------
|
||||
---------------
|
||||
|
||||
Default: ``""``
|
||||
|
||||
@ -1029,7 +1029,7 @@ is appropriate if you expect occasional downtime from the master(s).
|
||||
|
||||
master_tries: 1
|
||||
|
||||
.. conf_minion:: acceptance_wait_time_max
|
||||
.. conf_minion:: auth_tries
|
||||
|
||||
``auth_tries``
|
||||
--------------
|
||||
@ -1297,8 +1297,7 @@ Changes the underlying transport layer. ZeroMQ is the recommended transport
|
||||
while additional transport layers are under development. Supported values are
|
||||
``zeromq``, ``raet`` (experimental), and ``tcp`` (experimental). This setting has
|
||||
a significant impact on performance and should not be changed unless you know
|
||||
what you are doing! Transports are explained in :ref:`Salt Transports
|
||||
<transports>`.
|
||||
what you are doing!
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -1647,7 +1646,7 @@ below.
|
||||
Default: ``-1``
|
||||
|
||||
Specify a max size (in bytes) for modules on import. This feature is currently
|
||||
only supported on *nix operating systems and requires psutil.
|
||||
only supported on \*NIX operating systems and requires psutil.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -2714,7 +2713,7 @@ Thread Settings
|
||||
.. conf_minion:: multiprocessing
|
||||
|
||||
``multiprocessing``
|
||||
-------
|
||||
-------------------
|
||||
|
||||
Default: ``True``
|
||||
|
||||
@ -2731,7 +2730,7 @@ executed in a thread.
|
||||
.. conf_minion:: process_count_max
|
||||
|
||||
``process_count_max``
|
||||
-------
|
||||
---------------------
|
||||
|
||||
.. versionadded:: 2018.3.0
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
===========================
|
||||
==========================
|
||||
salt.engines.napalm_syslog
|
||||
===========================
|
||||
==========================
|
||||
|
||||
.. automodule:: salt.engines.napalm_syslog
|
||||
:members:
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
=================
|
||||
====================
|
||||
salt.grains.metadata
|
||||
=================
|
||||
====================
|
||||
|
||||
.. automodule:: salt.grains.metadata
|
||||
:members:
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
.. __unicode:
|
||||
.. _unicode:
|
||||
|
||||
===============
|
||||
Unicode in Salt
|
||||
@ -12,19 +12,29 @@ several basic rules to help developers handle Unicode correctly.
|
||||
|
||||
Salt's basic workflow for Unicode handling is as follows:
|
||||
|
||||
1) Salt should convert whatever data is passed on CLI/API to Unicode. Internally,
|
||||
everything that Salt does should be Unicode unless it is printing to the screen
|
||||
or writing to storage.
|
||||
1) Salt should convert whatever data is passed on CLI/API to Unicode.
|
||||
Internally, everything that Salt does should be Unicode unless it is
|
||||
printing to the screen or writing to storage.
|
||||
|
||||
2) Modules and various Salt pluggable systems use incoming data assuming Unicode.
|
||||
|
||||
2.1) For Salt modules that query an API; the module should convert the data received from the API into Unicode.
|
||||
2.1) For Salt modules that query an API; the module should convert the data
|
||||
received from the API into Unicode.
|
||||
|
||||
2.2) For Salt modules that shell out to get output; the module should convert data received into Unicode. (This does not apply if using the `cmd` execution module, which should handle this for you.
|
||||
2.2) For Salt modules that shell out to get output; the module should
|
||||
convert data received into Unicode. (This does not apply if using the
|
||||
:mod:`cmd <salt.modules.cmdmod>` execution module, which should handle
|
||||
this for you.
|
||||
|
||||
2.3) For Salt modules which print directly to the console (not via an outputter) or which write directly to disk, a string should be encoded when appropriate. To handle this conversion, the global variable `__salt_system_encoding__` is available, which declares the locale of the system that Salt is running on.
|
||||
2.3) For Salt modules which print directly to the console (not via an
|
||||
outputter) or which write directly to disk, a string should be encoded
|
||||
when appropriate. To handle this conversion, the global variable
|
||||
``__salt_system_encoding__`` is available, which declares the locale of
|
||||
the system that Salt is running on.
|
||||
|
||||
3) When a function in a Salt module returns, it should return Unicode.
|
||||
3) When a function in a Salt module returns a string, it should return a
|
||||
``unicode`` type in Python 2.
|
||||
|
||||
4) When Salt delivers the data to an outputter or a returner, it is the job of the outputter
|
||||
or returner to encode the Unicode before displaying it on the console or writing it to storage.
|
||||
4) When Salt delivers the data to an outputter or a returner, it is the job of
|
||||
the outputter or returner to encode the Unicode before displaying it on the
|
||||
console or writing it to storage.
|
||||
|
||||
@ -11,6 +11,8 @@ execution modules
|
||||
salt.modules.group
|
||||
salt.modules.kernelpkg
|
||||
salt.modules.pkg
|
||||
salt.modules.service
|
||||
salt.modules.shadow
|
||||
salt.modules.user
|
||||
|
||||
.. currentmodule:: salt.modules
|
||||
@ -96,7 +98,6 @@ execution modules
|
||||
cron
|
||||
csf
|
||||
cyg
|
||||
cytest
|
||||
daemontools
|
||||
data
|
||||
datadog_api
|
||||
@ -485,7 +486,6 @@ execution modules
|
||||
win_system
|
||||
win_task
|
||||
win_timezone
|
||||
win_update
|
||||
win_useradd
|
||||
win_wua
|
||||
x509
|
||||
@ -502,5 +502,6 @@ execution modules
|
||||
znc
|
||||
zoneadm
|
||||
zonecfg
|
||||
zookeeper
|
||||
zpool
|
||||
zypper
|
||||
|
||||
@ -1,5 +0,0 @@
|
||||
salt.modules.cytest module
|
||||
==========================
|
||||
|
||||
.. automodule:: salt.modules.cytest
|
||||
:members:
|
||||
@ -1,5 +1,5 @@
|
||||
salt.modules.libcloud_storage module
|
||||
================================
|
||||
salt.modules.libcloud_storage
|
||||
=============================
|
||||
|
||||
.. automodule:: salt.modules.libcloud_storage
|
||||
:members:
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
salt.modules.napalm_network module
|
||||
===============================
|
||||
==================================
|
||||
|
||||
.. automodule:: salt.modules.napalm_network
|
||||
:members:
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
===================
|
||||
=====================
|
||||
salt.modules.opsgenie
|
||||
===================
|
||||
=====================
|
||||
|
||||
.. automodule:: salt.modules.opsgenie
|
||||
:members:
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
===================
|
||||
==================
|
||||
salt.modules.panos
|
||||
===================
|
||||
==================
|
||||
|
||||
.. automodule:: salt.modules.panos
|
||||
:members:
|
||||
:members:
|
||||
|
||||
@ -30,7 +30,7 @@ Execution Module Used for
|
||||
:py:mod:`~salt.modules.solarispkg` Solaris-based OSes using ``pkgadd(1M)``
|
||||
:py:mod:`~salt.modules.solarisips` Solaris-based OSes using IPS ``pkg(1)``
|
||||
:py:mod:`~salt.modules.win_pkg` Salt's :ref:`Windows Package Manager
|
||||
<windows-package-manager`
|
||||
<windows-package-manager>`
|
||||
:py:mod:`~salt.modules.yumpkg` RedHat-based distros and derivatives
|
||||
using ``yum(8)`` or ``dnf(8)``
|
||||
:py:mod:`~salt.modules.zypper` SUSE-based distros using ``zypper(8)``
|
||||
|
||||
@ -33,7 +33,3 @@ Execution Module Used for
|
||||
:py:mod:`~salt.modules.win_service` Windows
|
||||
====================================== ========================================
|
||||
|
||||
|
|
||||
|
||||
.. automodule:: salt.modules.service
|
||||
:members:
|
||||
|
||||
@ -18,9 +18,3 @@ Execution Module Used for
|
||||
:py:mod:`~salt.modules.solaris_shadow` Solaris-based OSes
|
||||
:py:mod:`~salt.modules.win_shadow` Windows
|
||||
====================================== ========================================
|
||||
|
||||
|
|
||||
|
||||
.. automodule:: salt.modules.shadow
|
||||
:members:
|
||||
|
||||
|
||||
@ -1,6 +0,0 @@
|
||||
=======================
|
||||
salt.modules.win_update
|
||||
=======================
|
||||
|
||||
.. automodule:: salt.modules.win_update
|
||||
:members:
|
||||
@ -137,7 +137,7 @@ call functions available in other execution modules.
|
||||
The variable ``__salt__`` is packed into the modules after they are loaded into
|
||||
the Salt minion.
|
||||
|
||||
The ``__salt__`` variable is a :ref:`Python dictionary <python2:typesmapping>`
|
||||
The ``__salt__`` variable is a :ref:`Python dictionary <typesmapping>`
|
||||
containing all of the Salt functions. Dictionary keys are strings representing
|
||||
the names of the modules and the values are the functions themselves.
|
||||
|
||||
@ -157,6 +157,7 @@ Calling Execution Modules on the Salt Master
|
||||
============================================
|
||||
|
||||
.. versionadded:: 2016.11.0
|
||||
|
||||
Execution modules can now also be called via the :command:`salt-run` command
|
||||
using the :ref:`salt runner <salt_salt_runner>`.
|
||||
|
||||
@ -175,8 +176,8 @@ Grains Data
|
||||
-----------
|
||||
|
||||
The values detected by the Salt Grains on the minion are available in a
|
||||
:ref:`dict <python2:typesmapping>` named ``__grains__`` and can be accessed
|
||||
from within callable objects in the Python modules.
|
||||
:ref:`Python dictionary <typesmapping>` named ``__grains__`` and can be
|
||||
accessed from within callable objects in the Python modules.
|
||||
|
||||
To see the contents of the grains dictionary for a given system in your
|
||||
deployment run the :func:`grains.items` function:
|
||||
@ -287,7 +288,7 @@ Virtual module names are set using the ``__virtual__`` function and the
|
||||
``__virtual__`` Function
|
||||
========================
|
||||
|
||||
The ``__virtual__`` function returns either a :ref:`string <python2:typesseq>`,
|
||||
The ``__virtual__`` function returns either a :ref:`string <typesseq>`,
|
||||
:py:data:`True`, :py:data:`False`, or :py:data:`False` with an :ref:`error
|
||||
string <modules-error-info>`. If a string is returned then the module is loaded
|
||||
using the name of the string as the virtual name. If ``True`` is returned the
|
||||
@ -509,7 +510,7 @@ To add documentation add a `Python docstring`_ to the function.
|
||||
Now when the sys.doc call is executed the docstring will be cleanly returned
|
||||
to the calling terminal.
|
||||
|
||||
.. _`Python docstring`: http://docs.python.org/2/glossary.html#term-docstring
|
||||
.. _`Python docstring`: https://docs.python.org/3/glossary.html#term-docstring
|
||||
|
||||
Documentation added to execution modules in docstrings will automatically be
|
||||
added to the online web-based documentation.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
================
|
||||
=================
|
||||
salt.proxy.napalm
|
||||
================
|
||||
=================
|
||||
|
||||
.. automodule:: salt.proxy.napalm
|
||||
:members:
|
||||
|
||||
@ -127,7 +127,7 @@ Other render pipeline combinations include:
|
||||
The following is a contrived example SLS file using the ``jinja|mako|yaml``
|
||||
render pipeline:
|
||||
|
||||
.. code-block:: python
|
||||
.. code-block:: text
|
||||
|
||||
#!jinja|mako|yaml
|
||||
|
||||
|
||||
@ -80,9 +80,9 @@ Other optional functions can be included to add support for
|
||||
'''
|
||||
# Get a redis connection
|
||||
serv = redis.Redis(
|
||||
host='redis-serv.example.com',
|
||||
port=6379,
|
||||
db='0')
|
||||
host='redis-serv.example.com',
|
||||
port=6379,
|
||||
db='0')
|
||||
serv.sadd("%(id)s:jobs" % ret, ret['jid'])
|
||||
serv.set("%(jid)s:%(id)s" % ret, salt.utils.json.dumps(ret['return']))
|
||||
serv.sadd('jobs', ret['jid'])
|
||||
|
||||
@ -75,7 +75,6 @@ state modules
|
||||
debconfmod
|
||||
dellchassis
|
||||
disk
|
||||
docker
|
||||
docker_container
|
||||
docker_image
|
||||
docker_network
|
||||
@ -136,7 +135,6 @@ state modules
|
||||
jboss7
|
||||
jenkins
|
||||
junos
|
||||
k8s
|
||||
kapacitor
|
||||
kernelpkg
|
||||
keyboard
|
||||
@ -308,7 +306,6 @@ state modules
|
||||
win_smtp_server
|
||||
win_snmp
|
||||
win_system
|
||||
win_update
|
||||
win_wua
|
||||
winrepo
|
||||
x509
|
||||
@ -326,4 +323,5 @@ state modules
|
||||
zk_concurrency
|
||||
zfs
|
||||
zone
|
||||
zookeeper
|
||||
zpool
|
||||
|
||||
@ -1,6 +0,0 @@
|
||||
==================
|
||||
salt.states.docker
|
||||
==================
|
||||
|
||||
.. automodule:: salt.states.docker
|
||||
:members:
|
||||
@ -1,5 +1,5 @@
|
||||
salt.states.infoblox_a module
|
||||
===========================
|
||||
salt.states.infoblox_a
|
||||
======================
|
||||
|
||||
.. automodule:: salt.states.infoblox_a
|
||||
:members:
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
salt.states.infoblox_cname module
|
||||
===========================
|
||||
salt.states.infoblox_cname
|
||||
==========================
|
||||
|
||||
.. automodule:: salt.states.infoblox_cname
|
||||
:members:
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
salt.states.infoblox_host_record module
|
||||
===========================
|
||||
salt.states.infoblox_host_record
|
||||
================================
|
||||
|
||||
.. automodule:: salt.states.infoblox_host_record
|
||||
:members:
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
salt.states.infoblox_range module
|
||||
===========================
|
||||
salt.states.infoblox_range
|
||||
==========================
|
||||
|
||||
.. automodule:: salt.states.infoblox_range
|
||||
:members:
|
||||
|
||||
@ -1,6 +0,0 @@
|
||||
===============
|
||||
salt.states.k8s
|
||||
===============
|
||||
|
||||
.. automodule:: salt.states.k8s
|
||||
:members:
|
||||
@ -1,6 +1,6 @@
|
||||
================
|
||||
=================
|
||||
salt.states.panos
|
||||
================
|
||||
=================
|
||||
|
||||
.. automodule:: salt.states.panos
|
||||
:members:
|
||||
:members:
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
======------============
|
||||
========================
|
||||
salt.states.rbac_solaris
|
||||
========================
|
||||
|
||||
|
||||
@ -1,6 +0,0 @@
|
||||
======================
|
||||
salt.states.win_update
|
||||
======================
|
||||
|
||||
.. automodule:: salt.states.win_update
|
||||
:members:
|
||||
@ -1,3 +1,5 @@
|
||||
.. _compiler-ordering:
|
||||
|
||||
=====================================
|
||||
Understanding State Compiler Ordering
|
||||
=====================================
|
||||
|
||||
@ -10,6 +10,8 @@ But the situation may exist, where you would want all state execution to stop
|
||||
if a single state execution fails. The capability to do this is called
|
||||
``failing hard``.
|
||||
|
||||
.. _state-level-failhard:
|
||||
|
||||
State Level Failhard
|
||||
====================
|
||||
|
||||
@ -36,6 +38,8 @@ executed.
|
||||
It is possible to override a Global Failhard (see below) by explicitly setting
|
||||
it to ``False`` in the state.
|
||||
|
||||
.. _global-failhard:
|
||||
|
||||
Global Failhard
|
||||
===============
|
||||
|
||||
@ -52,5 +56,5 @@ in states not being executed or even checked. It can also be confusing to
|
||||
see states failhard if an admin is not actively aware that the failhard has
|
||||
been set.
|
||||
|
||||
To use the global failhard set failhard: True in the master configuration
|
||||
file.
|
||||
To use the global failhard set :conf_master:`failhard` to ``True`` in the
|
||||
master configuration file.
|
||||
|
||||
@ -24,7 +24,7 @@ the targeting state. The following example demonstrates a direct requisite:
|
||||
.. code-block:: yaml
|
||||
|
||||
vim:
|
||||
pkg.installed: []
|
||||
pkg.installed
|
||||
|
||||
/etc/vimrc:
|
||||
file.managed:
|
||||
@ -86,7 +86,7 @@ State target matching
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In order to understand how state targets are matched, it is helpful to know
|
||||
:ref:`how the state compiler is working <compiler_ordering>`. Consider the following
|
||||
:ref:`how the state compiler is working <compiler-ordering>`. Consider the following
|
||||
example:
|
||||
|
||||
.. code-block:: yaml
|
||||
@ -673,7 +673,7 @@ id declaration. This is useful when many files need to have the same defaults.
|
||||
- group: apache
|
||||
- mode: 755
|
||||
|
||||
/etc/bar.conf
|
||||
/etc/bar.conf:
|
||||
file.managed:
|
||||
- source: salt://bar.conf
|
||||
- use:
|
||||
@ -869,7 +869,7 @@ See :ref:`Reloading Modules <reloading-modules>`.
|
||||
- reload_grains: true
|
||||
|
||||
grains_read:
|
||||
module.run:
|
||||
module.run:
|
||||
- name: grains.items
|
||||
|
||||
.. _unless-requisite:
|
||||
@ -1024,10 +1024,10 @@ same privileges as the salt-minion.
|
||||
comment-repo:
|
||||
file.replace:
|
||||
- name: /etc/yum.repos.d/fedora.repo
|
||||
- pattern: ^enabled=0
|
||||
- pattern: '^enabled=0'
|
||||
- repl: enabled=1
|
||||
- check_cmd:
|
||||
- ! grep 'enabled=0' /etc/yum.repos.d/fedora.repo
|
||||
- "! grep 'enabled=0' /etc/yum.repos.d/fedora.repo"
|
||||
|
||||
This will attempt to do a replace on all ``enabled=0`` in the .repo file, and
|
||||
replace them with ``enabled=1``. The ``check_cmd`` is just a bash command. It
|
||||
|
||||
@ -249,8 +249,8 @@ Match Type Description
|
||||
============ ================================================================================================================
|
||||
glob Full minion ID or glob expression to match multiple minions (e.g. ``minion123`` or ``minion*``)
|
||||
pcre Perl-compatible regular expression (PCRE) matching a minion ID (e.g. ``web[0-3].domain.com``)
|
||||
grain Match a :ref:`grain <grain>`, optionally using globbing (e.g. ``kernel:Linux`` or ``kernel:*BSD``)
|
||||
grain_pcre Match a :ref:`grain <grain>` using PCRE (e.g. ``kernel:(Free|Open)BSD``)
|
||||
grain Match a :ref:`grain <grains>`, optionally using globbing (e.g. ``kernel:Linux`` or ``kernel:*BSD``)
|
||||
grain_pcre Match a :ref:`grain <grains>` using PCRE (e.g. ``kernel:(Free|Open)BSD``)
|
||||
list Comma-separated list of minions (e.g. ``minion1,minion2,minion3``)
|
||||
pillar :ref:`Pillar <pillar>` match, optionally using globbing (e.g. ``role:webserver`` or ``role:web*``)
|
||||
pillar_pcre :ref:`Pillar <pillar>` match using PCRE (e.g. ``role:web(server|proxy)``
|
||||
|
||||
@ -20,7 +20,7 @@ illustrate:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
/etc/salt/master: # maps to "name"
|
||||
/etc/salt/master: # maps to "name", unless a "name" argument is specified below
|
||||
file.managed: # maps to <filename>.<function> - e.g. "managed" in https://github.com/saltstack/salt/tree/develop/salt/states/file.py
|
||||
- user: root # one of many options passed to the manage function
|
||||
- group: root
|
||||
@ -50,22 +50,115 @@ directly define the user interface.
|
||||
.. _here: https://github.com/saltstack/salt/blob/v0.16.2/salt/states/pkgrepo.py#L163-183
|
||||
|
||||
|
||||
Best Practices
|
||||
==============
|
||||
|
||||
A well-written state function will follow these steps:
|
||||
|
||||
.. note::
|
||||
This is an extremely simplified example. Feel free to browse the `source
|
||||
code`_ for Salt's state modules to see other examples.
|
||||
|
||||
.. _`source code`: https://github.com/saltstack/salt/tree/develop/salt/states
|
||||
|
||||
1. Set up the return dictionary and perform any necessary input validation
|
||||
(type checking, looking for use of mutually-exclusive arguments, etc.).
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
ret = {'name': name,
|
||||
'result': False,
|
||||
'changes': {},
|
||||
'comment': ''}
|
||||
|
||||
if foo and bar:
|
||||
ret['comment'] = 'Only one of foo and bar is permitted'
|
||||
return ret
|
||||
|
||||
2. Check if changes need to be made. This is best done with an
|
||||
information-gathering function in an accompanying :ref:`execution module
|
||||
<writing-execution-modules>`. The state should be able to use the return
|
||||
from this function to tell whether or not the minion is already in the
|
||||
desired state.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
result = __salt__['modname.check'](name)
|
||||
|
||||
3. If step 2 found that the minion is already in the desired state, then exit
|
||||
immediately with a ``True`` result and without making any changes.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
if result:
|
||||
ret['result'] = True
|
||||
ret['comment'] = '{0} is already installed'.format(name)
|
||||
return ret
|
||||
|
||||
4. If step 2 found that changes *do* need to be made, then check to see if the
|
||||
state was being run in test mode (i.e. with ``test=True``). If so, then exit
|
||||
with a ``None`` result, a relevant comment, and (if possible) a ``changes``
|
||||
entry describing what changes would be made.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
if __opts__['test']:
|
||||
ret['result'] = None
|
||||
ret['comment'] = '{0} would be installed'.format(name)
|
||||
ret['changes'] = result
|
||||
return ret
|
||||
|
||||
5. Make the desired changes. This should again be done using a function from an
|
||||
accompanying execution module. If the result of that function is enough to
|
||||
tell you whether or not an error occurred, then you can exit with a
|
||||
``False`` result and a relevant comment to explain what happened.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
result = __salt__['modname.install'](name)
|
||||
|
||||
6. Perform the same check from step 2 again to confirm whether or not the
|
||||
minion is in the desired state. Just as in step 2, this function should be
|
||||
able to tell you by its return data whether or not changes need to be made.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
ret['changes'] = __salt__['modname.check'](name)
|
||||
|
||||
As you can see here, we are setting the ``changes`` key in the return
|
||||
dictionary to the result of the ``modname.check`` function (just as we did
|
||||
in step 4). The assumption here is that the information-gathering function
|
||||
will return a dictionary explaining what changes need to be made. This may
|
||||
or may not fit your use case.
|
||||
|
||||
7. Set the return data and return!
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
if ret['changes']:
|
||||
ret['comment'] = '{0} failed to install'.format(name)
|
||||
else:
|
||||
ret['result'] = True
|
||||
ret['comment'] = '{0} was installed'.format(name)
|
||||
|
||||
return ret
|
||||
|
||||
Using Custom State Modules
|
||||
==========================
|
||||
|
||||
Place your custom state modules inside a ``_states`` directory within the
|
||||
:conf_master:`file_roots` specified by the master config file. These custom
|
||||
state modules can then be distributed in a number of ways. Custom state modules
|
||||
are distributed when :py:func:`state.apply <salt.modules.state.apply_>` is run,
|
||||
or by executing the :mod:`saltutil.sync_states
|
||||
Before the state module can be used, it must be distributed to minions. This
|
||||
can be done by placing them into ``salt://_states/``. They can then be
|
||||
distributed manually to minions by running :mod:`saltutil.sync_states
|
||||
<salt.modules.saltutil.sync_states>` or :mod:`saltutil.sync_all
|
||||
<salt.modules.saltutil.sync_all>` functions.
|
||||
<salt.modules.saltutil.sync_all>`. Alternatively, when running a
|
||||
:ref:`highstate <running-highstate>` custom types will automatically be synced.
|
||||
|
||||
Any custom states which have been synced to a minion, that are named the
|
||||
same as one of Salt's default set of states, will take the place of the default
|
||||
state with the same name. Note that a state's default name is its filename
|
||||
(i.e. ``foo.py`` becomes state ``foo``), but that its name can be overridden
|
||||
by using a :ref:`__virtual__ function <virtual-modules>`.
|
||||
Any custom states which have been synced to a minion, that are named the same
|
||||
as one of Salt's default set of states, will take the place of the default
|
||||
state with the same name. Note that a state module's name defaults to one based
|
||||
on its filename (i.e. ``foo.py`` becomes state module ``foo``), but that its
|
||||
name can be overridden by using a :ref:`__virtual__ function
|
||||
<virtual-modules>`.
|
||||
|
||||
Cross Calling Execution Modules from States
|
||||
===========================================
|
||||
@ -97,11 +190,12 @@ functions available in other state modules.
|
||||
The variable ``__states__`` is packed into the modules after they are loaded into
|
||||
the Salt minion.
|
||||
|
||||
The ``__states__`` variable is a :ref:`Python dictionary <python2:typesmapping>`
|
||||
containing all of the state modules. Dictionary keys are strings representing the
|
||||
names of the modules and the values are the functions themselves.
|
||||
The ``__states__`` variable is a :ref:`Python dictionary <typesmapping>`
|
||||
containing all of the state modules. Dictionary keys are strings representing
|
||||
the names of the modules and the values are the functions themselves.
|
||||
|
||||
Salt state modules can be cross-called by accessing the value in the ``__states__`` dict:
|
||||
Salt state modules can be cross-called by accessing the value in the
|
||||
``__states__`` dict:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
|
||||
@ -176,7 +176,7 @@ following on the event bus:
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
salt/beacon/larry/inotify//etc/important_file {
|
||||
{
|
||||
"_stamp": "2015-09-09T15:59:37.972753",
|
||||
"data": {
|
||||
"change": "IN_IGNORED",
|
||||
|
||||
@ -200,7 +200,7 @@ preferred:
|
||||
|
||||
``/srv/salt/apache/conf.sls``:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
{% set name = 'httpd' %}
|
||||
{% set tmpl = 'salt://apache/files/httpd.conf' %}
|
||||
@ -234,7 +234,7 @@ locations within a single state:
|
||||
|
||||
``/srv/salt/apache/conf.sls``:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
{% from "apache/map.jinja" import apache with context %}
|
||||
|
||||
@ -267,7 +267,8 @@ is not very modular to one that is:
|
||||
.. code-block:: yaml
|
||||
|
||||
httpd:
|
||||
pkg.installed: []
|
||||
pkg:
|
||||
- installed
|
||||
service.running:
|
||||
- enable: True
|
||||
|
||||
@ -331,7 +332,7 @@ modification of static values:
|
||||
|
||||
``/srv/salt/apache/map.jinja``:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
{% set apache = salt['grains.filter_by']({
|
||||
'Debian': {
|
||||
@ -357,7 +358,7 @@ modification of static values:
|
||||
|
||||
``/srv/salt/apache/init.sls``:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
{% from "apache/map.jinja" import apache with context %}
|
||||
|
||||
@ -387,7 +388,7 @@ to be broken into two states.
|
||||
|
||||
``/srv/salt/apache/map.jinja``:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
{% set apache = salt['grains.filter_by']({
|
||||
'Debian': {
|
||||
@ -414,7 +415,7 @@ to be broken into two states.
|
||||
|
||||
``/srv/salt/apache/init.sls``:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
{% from "apache/map.jinja" import apache with context %}
|
||||
|
||||
@ -427,7 +428,7 @@ to be broken into two states.
|
||||
|
||||
``/srv/salt/apache/conf.sls``:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
{% from "apache/map.jinja" import apache with context %}
|
||||
|
||||
@ -521,7 +522,7 @@ the associated pillar:
|
||||
|
||||
``/srv/salt/mysql/testerdb.sls``:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
testdb:
|
||||
mysql_database.present:
|
||||
@ -529,7 +530,7 @@ the associated pillar:
|
||||
|
||||
``/srv/salt/mysql/user.sls``:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
include:
|
||||
- mysql.testerdb
|
||||
|
||||
@ -289,11 +289,13 @@ Optional. If set, the VM will be added to the specified availability set.
|
||||
|
||||
volumes
|
||||
-------
|
||||
Optional. A list of dictionaries describing data disks to attach to the instance can
|
||||
be specified using this setting. The data disk dictionaries are passed entirely to the
|
||||
`Azure DataDisk object
|
||||
<https://docs.microsoft.com/en-us/python/api/azure.mgmt.compute.v2017_12_01.models.datadisk?view=azure-python>`_
|
||||
, so ad-hoc options can be handled as long as they are valid properties of the object.
|
||||
|
||||
Optional. A list of dictionaries describing data disks to attach to the
|
||||
instance can be specified using this setting. The data disk dictionaries are
|
||||
passed entirely to the `Azure DataDisk object
|
||||
<https://docs.microsoft.com/en-us/python/api/azure.mgmt.compute.v2017_12_01.models.datadisk?view=azure-python>`_,
|
||||
so ad-hoc options can be handled as long as they are valid properties of the
|
||||
object.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -328,7 +330,7 @@ Optional. Default is ``False``. Normally when a VM is deleted, its associated
|
||||
interfaces and IPs are retained. This is useful if you expect the deleted VM
|
||||
to be recreated with the same name and network settings. If you would like
|
||||
interfaces and IPs to be deleted when their associated VM is deleted, set this
|
||||
to ``True``.
|
||||
to ``True``.
|
||||
|
||||
userdata
|
||||
--------
|
||||
@ -347,14 +349,14 @@ How this is used depends on the operating system that is being deployed. If
|
||||
used, any ``userdata`` setting will be ignored.
|
||||
|
||||
userdata_sendkeys
|
||||
-------------
|
||||
-----------------
|
||||
Optional. Set to ``True`` in order to generate salt minion keys and provide
|
||||
them as variables to the userdata script when running it through the template
|
||||
renderer. The keys can be referenced as ``{{opts['priv_key']}}`` and
|
||||
``{{opts['pub_key']}}``.
|
||||
|
||||
userdata_template
|
||||
-------------
|
||||
-----------------
|
||||
Optional. Enter the renderer, such as ``jinja``, to be used for the userdata
|
||||
script template.
|
||||
|
||||
|
||||
@ -257,4 +257,4 @@ This has also been tested to work with pipes, if needed:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
script_args: | head
|
||||
script_args: '| head'
|
||||
|
||||
@ -2,7 +2,6 @@
|
||||
Getting Started With Dimension Data Cloud
|
||||
=========================================
|
||||
|
||||
|
||||
Dimension Data are a global IT Services company and form part of the NTT Group.
|
||||
Dimension Data provide IT-as-a-Service to customers around the globe on their
|
||||
cloud platform (Compute as a Service). The CaaS service is available either on
|
||||
@ -10,14 +9,15 @@ one of the public cloud instances or as a private instance on premises.
|
||||
|
||||
http://cloud.dimensiondata.com/
|
||||
|
||||
CaaS has its own non-standard `API`_ , SaltStack provides a
|
||||
wrapper on top of this `API`_ with common methods with other IaaS solutions and
|
||||
Public cloud providers. Therefore, you can use the Dimension Data
|
||||
module to communicate with both the public and private clouds.
|
||||
CaaS has its own non-standard API , SaltStack provides a wrapper on top of this
|
||||
API with common methods with other IaaS solutions and Public cloud providers.
|
||||
Therefore, you can use the Dimension Data module to communicate with both the
|
||||
public and private clouds.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
This driver requires the Python ``apache-libcloud`` and ``netaddr`` library to be installed.
|
||||
|
||||
|
||||
@ -53,13 +53,14 @@ Possible regions:
|
||||
driver: dimensiondata
|
||||
|
||||
.. note::
|
||||
.. versionchanged:: 2015.8.0
|
||||
|
||||
The ``provider`` parameter in cloud provider definitions was renamed to ``driver``. This
|
||||
change was made to avoid confusion with the ``provider`` parameter that is used in cloud profile
|
||||
definitions. Cloud provider definitions now use ``driver`` to refer to the Salt cloud module that
|
||||
provides the underlying functionality to connect to a cloud host, while cloud profiles continue
|
||||
to use ``provider`` to refer to provider configurations that you define.
|
||||
In version 2015.8.0, the ``provider`` parameter in cloud provider
|
||||
definitions was renamed to ``driver``. This change was made to avoid
|
||||
confusion with the ``provider`` parameter that is used in cloud profile
|
||||
definitions. Cloud provider definitions now use ``driver`` to refer to the
|
||||
Salt cloud module that provides the underlying functionality to connect to
|
||||
a cloud host, while cloud profiles continue to use ``provider`` to refer to
|
||||
provider configurations that you define.
|
||||
|
||||
Profiles
|
||||
========
|
||||
|
||||
@ -125,7 +125,6 @@ Cloud Provider Specifics
|
||||
Getting Started With Parallels <parallels>
|
||||
Getting Started With ProfitBricks <profitbricks>
|
||||
Getting Started With Proxmox <proxmox>
|
||||
Getting Started With Rackspace <rackspace>
|
||||
Getting Started With Scaleway <scaleway>
|
||||
Getting Started With Saltify <saltify>
|
||||
Getting Started With SoftLayer <softlayer>
|
||||
|
||||
@ -9,11 +9,11 @@ libvirt with qemu-kvm.
|
||||
http://www.libvirt.org/
|
||||
|
||||
Host Dependencies
|
||||
============
|
||||
=================
|
||||
* libvirt >= 1.2.18 (older might work)
|
||||
|
||||
Salt-Cloud Dependencies
|
||||
============
|
||||
=======================
|
||||
* libvirt-python
|
||||
|
||||
Provider Configuration
|
||||
|
||||
@ -27,7 +27,7 @@ This has also been tested to work with pipes, if needed:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
script_args: | head
|
||||
script_args: '| head'
|
||||
|
||||
|
||||
Selecting the File Transport
|
||||
|
||||
@ -156,136 +156,127 @@ command:
|
||||
|
||||
# salt-cloud --list-sizes my-profitbricks-config
|
||||
|
||||
.. versionadded:: Fluorine
|
||||
One or more public IP address can be reserved with the following command:
|
||||
.. versionchanged:: Fluorine
|
||||
|
||||
.. code-block:: bash
|
||||
One or more public IP address can be reserved with the following command:
|
||||
|
||||
# salt-cloud -f reserve_ipblock my-profitbricks-config location='us/ewr' size=1
|
||||
.. code-block:: bash
|
||||
|
||||
# salt-cloud -f reserve_ipblock my-profitbricks-config location='us/ewr' size=1
|
||||
|
||||
Profile Specifics:
|
||||
------------------
|
||||
|
||||
The following list explains some of the important properties.
|
||||
|
||||
size
|
||||
Can be one of the options listed in the output of the following command:
|
||||
- ``size`` - Can be one of the options listed in the output of the following
|
||||
command:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: bash
|
||||
|
||||
salt-cloud --list-sizes my-profitbricks-config
|
||||
salt-cloud --list-sizes my-profitbricks-config
|
||||
|
||||
image
|
||||
Can be one of the options listed in the output of the following command:
|
||||
- ``image`` - Can be one of the options listed in the output of the following
|
||||
command:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: bash
|
||||
|
||||
salt-cloud --list-images my-profitbricks-config
|
||||
salt-cloud --list-images my-profitbricks-config
|
||||
|
||||
image_alias
|
||||
Can be one of the options listed in the output of the following command:
|
||||
- ``image_alias`` - Can be one of the options listed in the output of the
|
||||
following command:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: bash
|
||||
|
||||
salt-cloud -f list_images my-profitbricks-config
|
||||
salt-cloud -f list_images my-profitbricks-config
|
||||
|
||||
disk_size
|
||||
This option allows you to override the size of the disk as defined by the
|
||||
size. The disk size is set in gigabytes (GB).
|
||||
- ``disk_size`` - This option allows you to override the size of the disk as
|
||||
defined by the size. The disk size is set in gigabytes (GB).
|
||||
|
||||
disk_type
|
||||
This option allow the disk type to be set to HDD or SSD. The default is
|
||||
HDD.
|
||||
- ``disk_type`` - This option allow the disk type to be set to HDD or SSD. The
|
||||
default is HDD.
|
||||
|
||||
.. versionadded:: Fluorine
|
||||
image_password
|
||||
A password is set on the image for the "root" or "Administrator" account.
|
||||
This field may only be set during volume creation. Only valid with
|
||||
ProfitBricks supplied HDD (not ISO) images. The password must contain at
|
||||
least 8 and no more than 50 characters. Only these characters are
|
||||
allowed: [a-z][A-Z][0-9]
|
||||
.. versionadded:: Fluorine
|
||||
|
||||
cores
|
||||
This option allows you to override the number of CPU cores as defined by
|
||||
the size.
|
||||
- ``image_password`` - A password is set on the image for the "root" or
|
||||
"Administrator" account. This field may only be set during volume creation.
|
||||
Only valid with ProfitBricks supplied HDD (not ISO) images. The password must
|
||||
contain at least 8 and no more than 50 characters. Only these characters are
|
||||
allowed: [a-z][A-Z][0-9]
|
||||
|
||||
ram
|
||||
This option allows you to override the amount of RAM defined by the size.
|
||||
The value must be a multiple of 256, e.g. 256, 512, 768, 1024, and so
|
||||
forth.
|
||||
- ``cores`` - This option allows you to override the number of CPU cores as
|
||||
defined by the size.
|
||||
|
||||
public_lan
|
||||
This option will connect the server to the specified public LAN. If no
|
||||
LAN exists, then a new public LAN will be created. The value accepts a LAN
|
||||
ID (integer).
|
||||
- ``ram`` - This option allows you to override the amount of RAM defined by the
|
||||
size. The value must be a multiple of 256, e.g. 256, 512, 768, 1024, and so
|
||||
forth.
|
||||
|
||||
.. versionadded:: Fluorine
|
||||
public_ips
|
||||
Public IPs assigned to the NIC in the public LAN.
|
||||
- ``public_lan`` - This option will connect the server to the specified public
|
||||
LAN. If no LAN exists, then a new public LAN will be created. The value
|
||||
accepts a LAN ID (integer).
|
||||
|
||||
public_firewall_rules
|
||||
This option allows for a list of firewall rules assigned to the public
|
||||
network interface.
|
||||
.. versionadded:: Fluorine
|
||||
|
||||
Firewall Rule Name:
|
||||
protocol: <protocol> (TCP, UDP, ICMP)
|
||||
source_mac: <source-mac>
|
||||
source_ip: <source-ip>
|
||||
target_ip: <target-ip>
|
||||
port_range_start: <port-range-start>
|
||||
port_range_end: <port-range-end>
|
||||
icmp_type: <icmp-type>
|
||||
icmp_code: <icmp-code>
|
||||
- ``public_ips`` - Public IPs assigned to the NIC in the public LAN.
|
||||
|
||||
private_lan
|
||||
This option will connect the server to the specified private LAN. If no
|
||||
LAN exists, then a new private LAN will be created. The value accepts a LAN
|
||||
ID (integer).
|
||||
- ``public_firewall_rules`` - This option allows for a list of firewall rules
|
||||
assigned to the public network interface.
|
||||
|
||||
.. versionadded:: Fluorine
|
||||
private_ips
|
||||
Private IPs assigned in the private LAN. NAT setting is ignored when this setting is active.
|
||||
.. code-block:: yaml
|
||||
|
||||
private_firewall_rules
|
||||
This option allows for a list of firewall rules assigned to the private
|
||||
network interface.
|
||||
Firewall Rule Name:
|
||||
protocol: <protocol> (TCP, UDP, ICMP)
|
||||
source_mac: <source-mac>
|
||||
source_ip: <source-ip>
|
||||
target_ip: <target-ip>
|
||||
port_range_start: <port-range-start>
|
||||
port_range_end: <port-range-end>
|
||||
icmp_type: <icmp-type>
|
||||
icmp_code: <icmp-code>
|
||||
|
||||
Firewall Rule Name:
|
||||
protocol: <protocol> (TCP, UDP, ICMP)
|
||||
source_mac: <source-mac>
|
||||
source_ip: <source-ip>
|
||||
target_ip: <target-ip>
|
||||
port_range_start: <port-range-start>
|
||||
port_range_end: <port-range-end>
|
||||
icmp_type: <icmp-type>
|
||||
icmp_code: <icmp-code>
|
||||
- ``private_lan`` - This option will connect the server to the specified
|
||||
private LAN. If no LAN exists, then a new private LAN will be created. The
|
||||
value accepts a LAN ID (integer).
|
||||
|
||||
ssh_private_key
|
||||
Full path to the SSH private key file.
|
||||
.. versionadded:: Fluorine
|
||||
|
||||
ssh_public_key
|
||||
Full path to the SSH public key file.
|
||||
- ``private_ips`` - Private IPs assigned in the private LAN. NAT setting is
|
||||
ignored when this setting is active.
|
||||
|
||||
ssh_interface
|
||||
This option will use the private LAN IP for node connections (such as
|
||||
as bootstrapping the node) instead of the public LAN IP. The value accepts
|
||||
'private_lan'.
|
||||
- ``private_firewall_rules`` - This option allows for a list of firewall rules
|
||||
assigned to the private network interface.
|
||||
|
||||
cpu_family
|
||||
This option allow the CPU family to be set to AMD_OPTERON or INTEL_XEON.
|
||||
The default is AMD_OPTERON.
|
||||
.. code-block:: yaml
|
||||
|
||||
volumes:
|
||||
This option allows a list of additional volumes by name that will be
|
||||
created and attached to the server. Each volume requires 'disk_size'
|
||||
and, optionally, 'disk_type'. The default is HDD.
|
||||
Firewall Rule Name:
|
||||
protocol: <protocol> (TCP, UDP, ICMP)
|
||||
source_mac: <source-mac>
|
||||
source_ip: <source-ip>
|
||||
target_ip: <target-ip>
|
||||
port_range_start: <port-range-start>
|
||||
port_range_end: <port-range-end>
|
||||
icmp_type: <icmp-type>
|
||||
icmp_code: <icmp-code>
|
||||
|
||||
deploy
|
||||
Set to False if Salt should not be installed on the node.
|
||||
- ``ssh_private_key`` - Full path to the SSH private key file
|
||||
|
||||
wait_for_timeout
|
||||
The timeout to wait in seconds for provisioning resources such as servers.
|
||||
The default wait_for_timeout is 15 minutes.
|
||||
- ``ssh_public_key`` - Full path to the SSH public key file
|
||||
|
||||
- ``ssh_interface`` - This option will use the private LAN IP for node
|
||||
connections (such as as bootstrapping the node) instead of the public LAN IP.
|
||||
The value accepts 'private_lan'.
|
||||
|
||||
- ``cpu_family`` - This option allow the CPU family to be set to AMD_OPTERON or
|
||||
INTEL_XEON. The default is AMD_OPTERON.
|
||||
|
||||
- ``volumes`` - This option allows a list of additional volumes by name that
|
||||
will be created and attached to the server. Each volume requires 'disk_size'
|
||||
and, optionally, 'disk_type'. The default is HDD.
|
||||
|
||||
- ``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
|
||||
</topics/cloud/profiles>`.
|
||||
<salt-cloud-profiles>`.
|
||||
|
||||
@ -149,10 +149,10 @@ with their default settings listed.
|
||||
|
||||
# The name of the image, from ``salt-cloud --list-images proxmox``
|
||||
image: local:vztmpl/ubuntu-12.04-standard_12.04-1_amd64.tar.gz
|
||||
|
||||
|
||||
# Whether or not to verify the SSL cert on the Proxmox host
|
||||
verify_ssl: False
|
||||
|
||||
|
||||
# Network interfaces, netX
|
||||
net0: name=eth0,bridge=vmbr0,ip=dhcp
|
||||
|
||||
@ -172,7 +172,7 @@ QEMU profile file (for a new VM):
|
||||
|
||||
# Technology used to create the VM ('qemu', 'openvz'(on Proxmox <4.x) or 'lxc'(on Proxmox 4.x+))
|
||||
technology: qemu
|
||||
|
||||
|
||||
# Proxmox node name
|
||||
host: node_name
|
||||
|
||||
@ -187,7 +187,7 @@ QEMU profile file (for a new VM):
|
||||
|
||||
# OS Type enum (other / wxp / w2k / w2k3 / w2k8 / wvista / win7 / win8 / l24 / l26 / solaris)
|
||||
ostype: win7
|
||||
|
||||
|
||||
# Hard disk location
|
||||
sata0: <location>:<size>, format=<qcow2/vmdk/raw>, size=<size>GB #Example: local:120,format=qcow2,size=120GB
|
||||
|
||||
@ -231,7 +231,7 @@ QEMU profile file (for a clone):
|
||||
|
||||
# Technology used to create the VM ('qemu' or 'lxc')
|
||||
technology: qemu
|
||||
|
||||
|
||||
# Proxmox node name
|
||||
host: node_name
|
||||
|
||||
@ -244,5 +244,11 @@ QEMU profile file (for a clone):
|
||||
More information can be found on Proxmox API under the 'POST' method of /nodes/{node}/qemu/{vmid}/clone
|
||||
|
||||
.. note::
|
||||
The Proxmox API offers a lot more options and parameters, which are not yet supported by this salt-cloud 'overlay'. Feel free to add your contribution by forking the github repository and modifying the following file: salt/salt/cloud/clouds/proxmox.py
|
||||
An easy way to support more parameters for VM creation would be to add the names of the optional parameters in the 'create_nodes(vm_)' function, under the 'qemu' technology. But it requires you to dig into the code ...
|
||||
The Proxmox API offers a lot more options and parameters, which are not yet
|
||||
supported by this salt-cloud 'overlay'. Feel free to add your contribution
|
||||
by forking the github repository and modifying the following file:
|
||||
``salt/cloud/clouds/proxmox.py``
|
||||
|
||||
An easy way to support more parameters for VM creation would be to add the
|
||||
names of the optional parameters in the 'create_nodes(vm\_)' function, under
|
||||
the 'qemu' technology. But it requires you to dig into the code ...
|
||||
|
||||
@ -149,7 +149,7 @@ This has also been tested to work with pipes, if needed:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
script_args: | head
|
||||
script_args: '| head'
|
||||
|
||||
Remove Old SSH Keys
|
||||
===================
|
||||
|
||||
@ -28,8 +28,6 @@ The Virtualbox cloud module just needs to use the virtualbox driver for now. Vir
|
||||
driver: virtualbox
|
||||
|
||||
|
||||
.. _vmware-cloud-profile:
|
||||
|
||||
Profiles
|
||||
========
|
||||
|
||||
|
||||
@ -211,7 +211,7 @@ Set up an initial profile at ``/etc/salt/cloud.profiles`` or
|
||||
|
||||
hardware_version: 10
|
||||
image: centos64Guest
|
||||
|
||||
|
||||
#For Windows VM
|
||||
win_username: Administrator
|
||||
win_password: administrator
|
||||
@ -232,13 +232,14 @@ Set up an initial profile at ``/etc/salt/cloud.profiles`` or
|
||||
the current VM/template\'s vCPU count is used.
|
||||
|
||||
``cores_per_socket``
|
||||
.. versionadded:: 2016.11.0
|
||||
Enter the number of cores per vCPU that you want the VM/template to have. If not specified,
|
||||
this will default to 1.
|
||||
|
||||
.. note::
|
||||
this will default to 1.
|
||||
|
||||
Cores per socket should be less than or equal to the total number of vCPUs assigned to the VM/template.
|
||||
.. note::
|
||||
Cores per socket should be less than or equal to the total number of
|
||||
vCPUs assigned to the VM/template.
|
||||
|
||||
.. versionadded:: 2016.11.0
|
||||
|
||||
``memory``
|
||||
Enter the memory size (in MB or GB) that you want the VM/template to have. If
|
||||
@ -515,31 +516,31 @@ Set up an initial profile at ``/etc/salt/cloud.profiles`` or
|
||||
|
||||
``win_username``
|
||||
Specify windows vm administrator account.
|
||||
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
Windows template should have "administrator" account.
|
||||
|
||||
``win_password``
|
||||
Specify windows vm administrator account password.
|
||||
|
||||
|
||||
.. note::
|
||||
|
||||
During network configuration (if network specified), it is used to specify new administrator password for the machine.
|
||||
During network configuration (if network specified), it is used to specify new administrator password for the machine.
|
||||
|
||||
``win_organization_name``
|
||||
Specify windows vm user's organization. Default organization name is Organization
|
||||
VMware vSphere documentation:
|
||||
|
||||
|
||||
https://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/vim.vm.customization.UserData.html
|
||||
|
||||
``win_user_fullname``
|
||||
Specify windows vm user's fullname. Default fullname is "Windows User"
|
||||
VMware vSphere documentation:
|
||||
|
||||
|
||||
https://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/vim.vm.customization.UserData.html
|
||||
|
||||
``plain_text``
|
||||
``plain_text``
|
||||
Flag to specify whether or not the password is in plain text, rather than encrypted.
|
||||
VMware vSphere documentation:
|
||||
|
||||
@ -599,7 +600,7 @@ Example to reconfigure the memory and number of vCPUs:
|
||||
clonefrom: 'test-vm'
|
||||
|
||||
memory: 16GB
|
||||
num_cpus: 8
|
||||
num_cpus: 8
|
||||
|
||||
|
||||
Cloning a Template
|
||||
|
||||
@ -85,7 +85,7 @@ If supported by the cloud provider, a PowerShell script may be used to open up
|
||||
this port automatically, using the cloud provider's `userdata`. The following
|
||||
script would open up port 445, and apply the changes:
|
||||
|
||||
.. code-block:: powershell
|
||||
.. code-block:: text
|
||||
|
||||
<powershell>
|
||||
New-NetFirewallRule -Name "SMB445" -DisplayName "SMB445" -Protocol TCP -LocalPort 445
|
||||
@ -138,7 +138,7 @@ enabled in your userdata. By default EC2 Windows images only have insecure HTTP
|
||||
enabled. To enable HTTPS and basic authentication required by pywinrm consider
|
||||
the following userdata example:
|
||||
|
||||
.. code-block:: powershell
|
||||
.. code-block:: text
|
||||
|
||||
<powershell>
|
||||
New-NetFirewallRule -Name "SMB445" -DisplayName "SMB445" -Protocol TCP -LocalPort 445
|
||||
|
||||
@ -7,6 +7,7 @@ secure and troubleshoot, and how to perform many other administrative tasks.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:glob:
|
||||
|
||||
../../ref/configuration/master
|
||||
../../ref/configuration/minion
|
||||
@ -18,6 +19,7 @@ secure and troubleshoot, and how to perform many other administrative tasks.
|
||||
../jobs/job_cache
|
||||
../jobs/external_cache
|
||||
../../ref/configuration/logging/index
|
||||
../../ref/configuration/logging/handlers/*
|
||||
../../ref/file_server/index
|
||||
../tutorials/gitfs
|
||||
../tutorials/minionfs
|
||||
|
||||
@ -110,40 +110,51 @@ The typical lifecycle of a salt job from the perspective of the master
|
||||
might be as follows:
|
||||
|
||||
1) A command is issued on the CLI. For example, 'salt my_minion test.ping'.
|
||||
2) The 'salt' command uses LocalClient to generate a request to the salt master
|
||||
by connecting to the ReqServer on TCP:4506 and issuing the job.
|
||||
3) The salt-master ReqServer sees the request and passes it to an available
|
||||
MWorker over workers.ipc.
|
||||
4) A worker picks up the request and handles it. First, it checks to ensure
|
||||
that the requested user has permissions to issue the command. Then, it sends
|
||||
the publish command to all connected minions. For the curious, this happens
|
||||
in ClearFuncs.publish().
|
||||
5) The worker announces on the master event bus that it is about to publish
|
||||
a job to connected minions. This happens by placing the event on the master
|
||||
event bus (master_event_pull.ipc) where the EventPublisher picks it up and
|
||||
distributes it to all connected event listeners on master_event_pub.ipc.
|
||||
6) The message to the minions is encrypted and sent to the Publisher via IPC
|
||||
on publish_pull.ipc.
|
||||
7) Connected minions have a TCP session established with the Publisher on TCP
|
||||
port 4505 where they await commands. When the Publisher receives the job over
|
||||
publish_pull, it sends the jobs across the wire to the minions for processing.
|
||||
8) After the minions receive the request, they decrypt it and perform any
|
||||
requested work, if they determine that they are targeted to do so.
|
||||
9) When the minion is ready to respond, it publishes the result of its job back
|
||||
to the master by sending the encrypted result back to the master on TCP 4506
|
||||
where it is again picked up by the ReqServer and forwarded to an available
|
||||
MWorker for processing. (Again, this happens by passing this message across
|
||||
workers.ipc to an available worker.)
|
||||
10) When the MWorker receives the job it decrypts it and fires an event onto
|
||||
the master event bus (master_event_pull.ipc). (Again for the curious, this
|
||||
happens in AESFuncs._return().
|
||||
11) The EventPublisher sees this event and re-publishes it on the bus to all
|
||||
connected listeners of the master event bus (on master_event_pub.ipc). This
|
||||
is where the LocalClient has been waiting, listening to the event bus for
|
||||
minion replies. It gathers the job and stores the result.
|
||||
12) When all targeted minions have replied or the timeout has been exceeded,
|
||||
the salt client displays the results of the job to the user on the CLI.
|
||||
|
||||
2) The 'salt' command uses LocalClient to generate a request to the salt master
|
||||
by connecting to the ReqServer on TCP:4506 and issuing the job.
|
||||
|
||||
3) The salt-master ReqServer sees the request and passes it to an available
|
||||
MWorker over workers.ipc.
|
||||
|
||||
4) A worker picks up the request and handles it. First, it checks to ensure
|
||||
that the requested user has permissions to issue the command. Then, it sends
|
||||
the publish command to all connected minions. For the curious, this happens
|
||||
in ClearFuncs.publish().
|
||||
|
||||
5) The worker announces on the master event bus that it is about to publish a
|
||||
job to connected minions. This happens by placing the event on the master
|
||||
event bus (master_event_pull.ipc) where the EventPublisher picks it up and
|
||||
distributes it to all connected event listeners on master_event_pub.ipc.
|
||||
|
||||
6) The message to the minions is encrypted and sent to the Publisher via IPC on
|
||||
publish_pull.ipc.
|
||||
|
||||
7) Connected minions have a TCP session established with the Publisher on TCP
|
||||
port 4505 where they await commands. When the Publisher receives the job
|
||||
over publish_pull, it sends the jobs across the wire to the minions for
|
||||
processing.
|
||||
|
||||
8) After the minions receive the request, they decrypt it and perform any
|
||||
requested work, if they determine that they are targeted to do so.
|
||||
|
||||
9) When the minion is ready to respond, it publishes the result of its job back
|
||||
to the master by sending the encrypted result back to the master on TCP 4506
|
||||
where it is again picked up by the ReqServer and forwarded to an available
|
||||
MWorker for processing. (Again, this happens by passing this message across
|
||||
workers.ipc to an available worker.)
|
||||
|
||||
10) When the MWorker receives the job it decrypts it and fires an event onto
|
||||
the master event bus (master_event_pull.ipc). (Again for the curious, this
|
||||
happens in AESFuncs._return().
|
||||
|
||||
11) The EventPublisher sees this event and re-publishes it on the bus to all
|
||||
connected listeners of the master event bus (on master_event_pub.ipc). This
|
||||
is where the LocalClient has been waiting, listening to the event bus for
|
||||
minion replies. It gathers the job and stores the result.
|
||||
|
||||
12) When all targeted minions have replied or the timeout has been exceeded,
|
||||
the salt client displays the results of the job to the user on the CLI.
|
||||
|
||||
Salt Minion
|
||||
===========
|
||||
|
||||
@ -236,13 +236,13 @@ repository be sure to communicate with any other contributors there on pull
|
||||
requests that are large or have breaking changes.
|
||||
|
||||
In general it is best to have another Contributor review and merge any pull
|
||||
requests that you open. Feel free to `at-mention`__ other regular contributors
|
||||
requests that you open. Feel free to `at-mention`_ other regular contributors
|
||||
to a repository and request a review. However, there are a lot of formula
|
||||
repositories so if a repository does not yet have regular contributors or if
|
||||
your pull request has stayed open for more than a couple days feel free to
|
||||
"selfie-merge" your own pull request.
|
||||
|
||||
__: https://help.github.com/articles/basic-writing-and-formatting-syntax/#mentioning-users-and-teams
|
||||
.. _`at-mention`: https://help.github.com/articles/basic-writing-and-formatting-syntax/#mentioning-users-and-teams
|
||||
|
||||
Style
|
||||
-----
|
||||
@ -250,7 +250,7 @@ Style
|
||||
Maintainability, readability, and reusability are all marks of a good Salt sls
|
||||
file. This section contains several suggestions and examples.
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
# Deploy the stable master branch unless version overridden by passing
|
||||
# Pillar at the CLI or via the Reactor.
|
||||
@ -472,7 +472,7 @@ lookups.
|
||||
|
||||
Below is a simple example of a readable loop:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
{% for user in salt.pillar.get('list_of_users', []) %}
|
||||
|
||||
@ -489,7 +489,7 @@ Readability suffers and the correct YAML indentation is difficult to see in the
|
||||
surrounding visual noise. Parametrization (discussed below) and variables are
|
||||
both useful techniques to avoid this. For example:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
{# ---- Bad example ---- #}
|
||||
|
||||
@ -530,7 +530,7 @@ easily combined and merged. And they can be directly serialized into YAML which
|
||||
is often easier than trying to create valid YAML through templating. For
|
||||
example:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
{# ---- Bad example ---- #}
|
||||
|
||||
@ -624,7 +624,10 @@ example is a state tree of two sls files, one simple and one complicated.
|
||||
|
||||
common_users:
|
||||
user.present:
|
||||
- names: [larry, curly, moe]
|
||||
- names:
|
||||
- larry
|
||||
- curly
|
||||
- moe
|
||||
|
||||
``/srv/salt/roles_configuration``:
|
||||
|
||||
@ -676,7 +679,7 @@ above).
|
||||
|
||||
Macros are useful for creating reusable, parameterized states. For example:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
{% macro user_state(state_id, user_name, shell='/bin/bash', groups=[]) %}
|
||||
{{ state_id }}:
|
||||
@ -696,7 +699,7 @@ example, the following macro could be used to write a php.ini config file:
|
||||
|
||||
``/srv/salt/php.sls``:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
php_ini:
|
||||
file.managed:
|
||||
@ -793,7 +796,7 @@ syntax for referencing a value is a normal dictionary lookup in Jinja, such as
|
||||
Values defined in the map file can be fetched for the current platform in any
|
||||
state file using the following syntax:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
{% from "mysql/map.jinja" import mysql with context %}
|
||||
|
||||
@ -987,7 +990,7 @@ XML.)
|
||||
|
||||
``/srv/salt/tomcat/server_xml.sls``:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
{% import_yaml 'tomcat/defaults.yaml' as server_xml_defaults %}
|
||||
{% set server_xml_final_values = salt.pillar.get(
|
||||
@ -1022,7 +1025,7 @@ example:
|
||||
|
||||
``/srv/salt/app/deploy.sls``:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
{# Load the map file. #}
|
||||
{% import_yaml 'app/defaults.yaml' as app_defaults %}
|
||||
@ -1081,7 +1084,7 @@ The following is a best-practice example for a reusable Apache formula. (This
|
||||
skips platform-specific options for brevity. See the full
|
||||
:formula_url:`apache-formula` for more.)
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: text
|
||||
|
||||
# apache/init.sls
|
||||
apache:
|
||||
|
||||
@ -12,38 +12,38 @@ You can use Salt Extend to quickly create templated modules for adding new behav
|
||||
Salt Extend takes a template directory and merges it into a SaltStack source code directory.
|
||||
|
||||
Command line usage
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
------------------
|
||||
|
||||
*See* :ref:`salt-extend <salt-extend>`
|
||||
|
||||
Choosing a template
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
-------------------
|
||||
|
||||
The following templates are available:
|
||||
|
||||
module
|
||||
^^^^^^
|
||||
******
|
||||
|
||||
Creates a new execution module within salt/modules/{{module_name}}.py
|
||||
|
||||
module_unit
|
||||
^^^^^^^^^^^
|
||||
***********
|
||||
|
||||
Creates a new execution module unit test suite within tests/unit/modules/test_{{module_name}}.py
|
||||
|
||||
state
|
||||
^^^^^
|
||||
*****
|
||||
|
||||
Creates a new state module within salt/states/{{module_name}}.py
|
||||
|
||||
state_unit
|
||||
^^^^^^^^^^
|
||||
**********
|
||||
|
||||
Creates a new state module unit test suite within tests/unit/states/test_{{module_name}}.py
|
||||
|
||||
|
||||
Adding templates
|
||||
~~~~~~~~~~~~~~~~
|
||||
----------------
|
||||
|
||||
1. Create a directory under <src>/templates
|
||||
2. Create a file ``template.yml`` containing properties for
|
||||
@ -51,12 +51,12 @@ Adding templates
|
||||
* ``description`` - a description of the template
|
||||
* ``questions`` - a collection of additional questions to ask the user, the name of the item will
|
||||
be used as the key in the context dictionary within the jinja template.
|
||||
|
||||
|
||||
* ``question`` - The question to ask the user, as a string
|
||||
* ``default`` - (optional) the default value, can contain Jinja2 template syntax and has access to the default context properties
|
||||
|
||||
Example template.yml
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
********************
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -71,19 +71,19 @@ Example template.yml
|
||||
3. Create the files within <src>/templates/<your template> to match the target
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
File names can contain Jinja 2 template syntax, e.g. *'{{module_name}}.py}}'*
|
||||
|
||||
Example file in the template directory
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
**************************************
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
print('Hello {{module_name}}')
|
||||
__virtual__ = '{{__virtual_name__}}'
|
||||
|
||||
|
||||
Default context properties
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
**************************
|
||||
|
||||
The default context provides the following properties
|
||||
|
||||
@ -97,10 +97,10 @@ The default context provides the following properties
|
||||
As well as any additional properties entered from the questions section of ``template.yml``
|
||||
|
||||
API
|
||||
~~~
|
||||
---
|
||||
|
||||
salt.utils.extend module
|
||||
========================
|
||||
************************
|
||||
|
||||
.. automodule:: salt.utils.extend
|
||||
:members:
|
||||
|
||||
@ -8,7 +8,7 @@ Developing Salt
|
||||
|
||||
*
|
||||
extend/index
|
||||
tests/index
|
||||
tests/*
|
||||
raet/index
|
||||
git/index
|
||||
conventions/index
|
||||
|
||||
@ -4,98 +4,105 @@
|
||||
GitHub Labels and Milestones
|
||||
============================
|
||||
|
||||
SaltStack uses several label categories, as well as milestones, to triage incoming issues and pull requests in the
|
||||
GitHub issue tracker. Labels are used to sort issues by type, priority, severity, status, functional area, functional
|
||||
group, and targeted release and pull requests by status, functional area, functional group, type of change, and test
|
||||
status. Milestones are used to indicate whether an issue is fully triaged or is scheduled to be fixed by SaltStack in
|
||||
an upcoming sprint.
|
||||
SaltStack uses several label categories, as well as milestones, to triage
|
||||
incoming issues and pull requests in the GitHub issue tracker. Labels are used
|
||||
to sort issues by type, priority, severity, status, functional area, functional
|
||||
group, and targeted release and pull requests by status, functional area,
|
||||
functional group, type of change, and test status. Milestones are used to
|
||||
indicate whether an issue is fully triaged or is scheduled to be fixed by
|
||||
SaltStack in an upcoming sprint.
|
||||
|
||||
Milestones
|
||||
==========
|
||||
|
||||
All issues are assigned to a milestone, whereas pull requests are almost never assigned to a milestone as the mean
|
||||
lifetime of pull requests is short enough that there is no need to track them temporally.
|
||||
All issues are assigned to a milestone, whereas pull requests are almost never
|
||||
assigned to a milestone as the mean lifetime of pull requests is short enough
|
||||
that there is no need to track them temporally.
|
||||
|
||||
SaltStack uses milestones to indicate which issues are blocked on submitter or upstream actions, are approved, or are
|
||||
scheduled to be fixed or implemented in an upcoming sprint. If an issue is not attached to a sprint milestone, you are
|
||||
welcome to work on it at your own desire and convenience. If it is attached to a sprint milestone and you have already
|
||||
begun working on it or have a solution in mind or have other ideas related to the issue, you are encouraged to
|
||||
coordinate with the assignee via the GitHub issue tracker to create the best possible solution or implementation.
|
||||
SaltStack uses milestones to indicate which issues are blocked on submitter or
|
||||
upstream actions, are approved, or are scheduled to be fixed or implemented in
|
||||
an upcoming sprint. If an issue is not attached to a sprint milestone, you are
|
||||
welcome to work on it at your own desire and convenience. If it is attached to
|
||||
a sprint milestone and you have already begun working on it or have a solution
|
||||
in mind or have other ideas related to the issue, you are encouraged to
|
||||
coordinate with the assignee via the GitHub issue tracker to create the best
|
||||
possible solution or implementation.
|
||||
|
||||
``Approved``
|
||||
The issue has been validated and has all necessary information.
|
||||
- ``Approved`` - The issue has been validated and has all necessary information.
|
||||
|
||||
``Blocked``
|
||||
The issue is waiting on actions by parties outside of SaltStack, such as receiving more information from the
|
||||
submitter or resolution of an upstream issue. This milestone is usually applied in conjunction with the labels
|
||||
``Info Needed``, ``Question``, ``Expected Behavior``, ``Won't Fix For Now``, or ``Upstream Bug``.
|
||||
- ``Blocked`` - The issue is waiting on actions by parties outside of
|
||||
SaltStack, such as receiving more information from the submitter or
|
||||
resolution of an upstream issue. This milestone is usually applied in
|
||||
conjunction with the labels ``Info Needed``, ``Question``, ``Expected
|
||||
Behavior``, ``Won't Fix For Now``, or ``Upstream Bug``.
|
||||
|
||||
``Under Review``
|
||||
The issue is having further validation done by a SaltStack engineer.
|
||||
- ``Under Review`` - The issue is having further validation done by a SaltStack
|
||||
engineer.
|
||||
|
||||
``<Sprint>``
|
||||
The issue is being actively worked on by a SaltStack engineer. Sprint milestones names are constructed from the
|
||||
chemical symbol of the next release's codename and the number of sprints until that release is made. For example,
|
||||
if the next release codename is ``Neon`` and there are five sprints until that release, the corresponding sprint
|
||||
milestone will be called ``Ne 5``. See :ref:`<version-numbers>` for a discussion of Salt's release
|
||||
codenames.
|
||||
- ``<Sprint>`` - The issue is being actively worked on by a SaltStack engineer.
|
||||
Sprint milestones names are constructed from the chemical symbol of the next
|
||||
release's codename and the number of sprints until that release is made. For
|
||||
example, if the next release codename is ``Neon`` and there are five sprints
|
||||
until that release, the corresponding sprint milestone will be called ``Ne
|
||||
5``. See :ref:`here <version-numbers>` for a discussion of Salt's release
|
||||
codenames.
|
||||
|
||||
Labels
|
||||
======
|
||||
|
||||
Labels are used to sort and describe issues and pull requests. Some labels are usually reserved for one or the other,
|
||||
though most labels may be applied to both.
|
||||
Labels are used to sort and describe issues and pull requests. Some labels are
|
||||
usually reserved for one or the other, though most labels may be applied to
|
||||
both.
|
||||
|
||||
New issues will receive at least one label and a milestone, and new pull requests will receive at least one label.
|
||||
Except for the :ref:`functional area <functional-area-labels>` and :ref:`functional group <functional-group-labels>`
|
||||
label categories, issues will generally receive only up to one label per category.
|
||||
New issues will receive at least one label and a milestone, and new pull
|
||||
requests will receive at least one label. Except for the :ref:`functional area
|
||||
<functional-area-labels>` and :ref:`functional group <functional-group-labels>`
|
||||
label categories, issues will generally receive only up to one label per
|
||||
category.
|
||||
|
||||
Type
|
||||
----
|
||||
|
||||
Issues are categorized into one of several types. Type labels are almost never used for pull requests. GitHub treats
|
||||
pull requests like issues in many ways, so a pull request could be considered an issue with an implicit ``Pull Request``
|
||||
type label applied.
|
||||
Issues are categorized into one of several types. Type labels are almost never
|
||||
used for pull requests. GitHub treats pull requests like issues in many ways,
|
||||
so a pull request could be considered an issue with an implicit ``Pull
|
||||
Request`` type label applied.
|
||||
|
||||
``Feature``
|
||||
The issue is a request for new functionality including changes, enhancements, refactors, etc.
|
||||
- ``Feature`` - The issue is a request for new functionality including changes,
|
||||
enhancements, refactors, etc.
|
||||
|
||||
``Bug``
|
||||
The issue documents broken, incorrect, or confusing behavior. This label is always accompanied by a :ref:`severity
|
||||
label <bug-severity-labels>`.
|
||||
- ``Bug`` - The issue documents broken, incorrect, or confusing behavior. This
|
||||
label is always accompanied by a :ref:`severity label <bug-severity-labels>`.
|
||||
|
||||
``Duplicate``
|
||||
The issue is a duplicate of another feature request or bug report.
|
||||
- ``Duplicate`` - The issue is a duplicate of another feature request or bug
|
||||
report.
|
||||
|
||||
``Upstream Bug``
|
||||
The issue is a result of an upstream issue.
|
||||
- ``Upstream Bug`` - The issue is a result of an upstream issue.
|
||||
|
||||
``Question``
|
||||
The issue is more of a question than a request for new features or a report of broken features, but can sometimes
|
||||
lead to further discussion or changes of confusing or incongruous behavior or documentation.
|
||||
- ``Question`` - The issue is more of a question than a request for new
|
||||
features or a report of broken features, but can sometimes lead to further
|
||||
discussion or changes of confusing or incongruous behavior or documentation.
|
||||
|
||||
``Expected Behavior``
|
||||
The issue is a bug report of intended functionality.
|
||||
- ``Expected Behavior`` - The issue is a bug report of intended functionality.
|
||||
|
||||
Priority
|
||||
--------
|
||||
|
||||
An issue's priority is relative to its :ref:`functional area <functional-area-labels>`. If a bug report, for example,
|
||||
about ``gitfs`` indicates that all users of ``gitfs`` will encounter this bug, then a ``P1`` label will be applied, even
|
||||
though users who are not using ``gitfs`` will not encounter the bug. If a feature is requested by many users, it may be
|
||||
given a high priority.
|
||||
An issue's priority is relative to its :ref:`functional area
|
||||
<functional-area-labels>`. If a bug report, for example, about ``gitfs``
|
||||
indicates that all users of ``gitfs`` will encounter this bug, then a ``P1``
|
||||
label will be applied, even though users who are not using ``gitfs`` will not
|
||||
encounter the bug. If a feature is requested by many users, it may be given a
|
||||
high priority.
|
||||
|
||||
``P1``
|
||||
The issue will be seen by all users.
|
||||
- ``P1`` - The issue will be seen by all users.
|
||||
|
||||
``P2``
|
||||
The issue will be seen by most users.
|
||||
- ``P2`` - The issue will be seen by most users.
|
||||
|
||||
``P3``
|
||||
The issue will be seen by about half of users.
|
||||
- ``P3`` - The issue will be seen by about half of users.
|
||||
|
||||
``P4``
|
||||
The issue will not be seen by most users. Usually the issue is a very specific use case or corner case.
|
||||
- ``P4`` - The issue will not be seen by most users. Usually the issue is a
|
||||
very specific use case or corner case.
|
||||
|
||||
.. _bug-severity-labels:
|
||||
|
||||
@ -104,196 +111,219 @@ Severity
|
||||
|
||||
Severity labels are almost always only applied to issues labeled ``Bug``.
|
||||
|
||||
``Blocker``
|
||||
The issue is blocking an impending release.
|
||||
- ``Blocker`` - The issue is blocking an impending release.
|
||||
|
||||
``Critical``
|
||||
The issue causes data loss, crashes or hangs salt processes, makes the system unresponsive, etc.
|
||||
- ``Critical`` - The issue causes data loss, crashes or hangs salt processes,
|
||||
makes the system unresponsive, etc.
|
||||
|
||||
``High Severity``
|
||||
The issue reports incorrect functionality, bad functionality, a confusing user experience, etc.
|
||||
- ``High Severity`` - The issue reports incorrect functionality, bad
|
||||
functionality, a confusing user experience, etc.
|
||||
|
||||
``Medium Severity``
|
||||
The issue reports cosmetic items, formatting, spelling, colors, etc.
|
||||
- ``Medium Severity`` - The issue reports cosmetic items, formatting, spelling,
|
||||
colors, etc.
|
||||
|
||||
.. _functional-area-labels:
|
||||
|
||||
Functional Area
|
||||
---------------
|
||||
|
||||
Many major components of Salt have corresponding GitHub labels. These labels are applied to all issues and pull
|
||||
requests as is reasonably appropriate. They are useful in organizing issues and pull requests according to the source
|
||||
code relevant to issues or the source code changed by pull requests.
|
||||
Many major components of Salt have corresponding GitHub labels. These labels
|
||||
are applied to all issues and pull requests as is reasonably appropriate. They
|
||||
are useful in organizing issues and pull requests according to the source code
|
||||
relevant to issues or the source code changed by pull requests.
|
||||
|
||||
* ``Execution Module``
|
||||
* ``File Servers``
|
||||
* ``Grains``
|
||||
* ``Multi-Master``
|
||||
* ``Packaging`` Related to packaging of Salt, not Salt's support for package management.
|
||||
* ``Pillar``
|
||||
* ``RAET``
|
||||
* ``Returners``
|
||||
* ``Runners``
|
||||
* ``SPM``
|
||||
* ``Salt-API``
|
||||
* ``Salt-Cloud``
|
||||
* ``Salt-SSH``
|
||||
* ``Salt-Syndic``
|
||||
* ``State Module``
|
||||
* ``Tests``
|
||||
* ``Transport``
|
||||
* ``Windows``
|
||||
* ``ZMQ``
|
||||
- ``Execution Module``
|
||||
- ``File Servers``
|
||||
- ``Grains``
|
||||
- ``Multi-Master``
|
||||
- ``Packaging`` Related to packaging of Salt, not Salt's support for package management.
|
||||
- ``Pillar``
|
||||
- ``RAET``
|
||||
- ``Returners``
|
||||
- ``Runners``
|
||||
- ``SPM``
|
||||
- ``Salt-API``
|
||||
- ``Salt-Cloud``
|
||||
- ``Salt-SSH``
|
||||
- ``Salt-Syndic``
|
||||
- ``State Module``
|
||||
- ``Tests``
|
||||
- ``Transport``
|
||||
- ``Windows``
|
||||
- ``ZMQ``
|
||||
|
||||
.. _functional-group-labels:
|
||||
|
||||
Functional Group
|
||||
----------------
|
||||
|
||||
These labels sort issues and pull requests according to the internal SaltStack engineering teams.
|
||||
These labels sort issues and pull requests according to the internal SaltStack
|
||||
engineering teams.
|
||||
|
||||
``Core``
|
||||
The issue or pull request relates to code that is central or existential to Salt itself.
|
||||
- ``Core`` - The issue or pull request relates to code that is central or
|
||||
existential to Salt itself.
|
||||
|
||||
``Platform``
|
||||
The issue or pull request relates to support and integration with various platforms like traditional operating
|
||||
systems as well as containers, platform-based utilities like filesystems, command schedulers, etc., and
|
||||
system-based applications like webservers, databases, etc.
|
||||
- ``Platform`` - The issue or pull request relates to support and integration
|
||||
with various platforms like traditional operating systems as well as
|
||||
containers, platform-based utilities like filesystems, command schedulers,
|
||||
etc., and system-based applications like webservers, databases, etc.
|
||||
|
||||
``RIoT``
|
||||
The issue or pull request relates to support and integration with various abstract systems like cloud providers,
|
||||
hypervisors, API-based services, etc.
|
||||
- ``RIoT`` - The issue or pull request relates to support and integration with
|
||||
various abstract systems like cloud providers, hypervisors, API-based
|
||||
services, etc.
|
||||
|
||||
``Console``
|
||||
The issue or pull request relates to the SaltStack enterprise console.
|
||||
- ``Console`` - The issue or pull request relates to the SaltStack enterprise
|
||||
console.
|
||||
|
||||
``Documentation``
|
||||
The issue or pull request relates to documentation.
|
||||
- ``Documentation`` - The issue or pull request relates to documentation.
|
||||
|
||||
Status
|
||||
------
|
||||
|
||||
Status labels are used to define and track the state of issues and pull requests. Not all potential statuses correspond
|
||||
to a label, but some statuses are common enough that labels have been created for them. If an issue has not been moved
|
||||
beyond the ``Blocked`` milestone, it is very likely that it will only have a status label.
|
||||
Status labels are used to define and track the state of issues and pull
|
||||
requests. Not all potential statuses correspond to a label, but some statuses
|
||||
are common enough that labels have been created for them. If an issue has not
|
||||
been moved beyond the ``Blocked`` milestone, it is very likely that it will
|
||||
only have a status label.
|
||||
|
||||
``Bugfix - back-port``
|
||||
The pull request needs to be back-ported to an older release branch. This is done by :ref:`recreating the pull
|
||||
request <backporting-pull-requests>` against that branch. Once the back-port is completed, this label is replaced
|
||||
with a ``Bugfix - [Done] back-ported`` label. Normally, new features should go into the develop and bug fixes into
|
||||
the oldest supported release branch, see :ref:`<which-salt-branch>`.
|
||||
- ``Bugfix - back-port`` The pull request needs to be back-ported to an older
|
||||
release branch. This is done by :ref:`recreating the pull request
|
||||
<backporting-pull-requests>` against that branch. Once the back-port is
|
||||
completed, this label is replaced with a ``Bugfix - [Done] back-ported``
|
||||
label. Normally, new features should go into the develop and bug fixes into
|
||||
the oldest supported release branch, see :ref:`here <which-salt-branch>`.
|
||||
|
||||
``Bugfix - [Done] back-ported``
|
||||
The pull request has been back-ported to an older branch.
|
||||
- ``Bugfix - [Done] back-ported`` - The pull request has been back-ported to an
|
||||
older branch.
|
||||
|
||||
``Cannot Reproduce``
|
||||
The issue is a bug and has been reviewed by a SaltStack engineer, but it cannot be replicated with the provided
|
||||
information and context. Those involved with the bug will need to work through additional ideas until the bug can
|
||||
be isolated and verified.
|
||||
- ``Cannot Reproduce`` - The issue is a bug and has been reviewed by a
|
||||
SaltStack engineer, but it cannot be replicated with the provided information
|
||||
and context. Those involved with the bug will need to work through
|
||||
additional ideas until the bug can be isolated and verified.
|
||||
|
||||
``Confirmed``
|
||||
The issue is a bug and has been confirmed by a SaltStack engineer, who often documents a minimal working example
|
||||
that reproduces the bug.
|
||||
- ``Confirmed`` - The issue is a bug and has been confirmed by a SaltStack
|
||||
engineer, who often documents a minimal working example that reproduces the
|
||||
bug.
|
||||
|
||||
``Fixed Pending Verification``
|
||||
The issue is a bug and has been fixed by one or more pull requests, which should link to the issue. Closure of the
|
||||
issue is contingent upon confirmation of resolution from the submitter. If the submitter reports a negative
|
||||
confirmation, this label is removed. If no response is given after a few weeks, then the issue will be assumed
|
||||
fixed and closed.
|
||||
- ``Fixed Pending Verification`` - The issue is a bug and has been fixed by one
|
||||
or more pull requests, which should link to the issue. Closure of the issue
|
||||
is contingent upon confirmation of resolution from the submitter. If the
|
||||
submitter reports a negative confirmation, this label is removed. If no
|
||||
response is given after a few weeks, then the issue will be assumed fixed and
|
||||
closed.
|
||||
|
||||
``Info Needed``
|
||||
The issue needs more information before it can be verified and resolved. For a feature request this may include a
|
||||
description of the use cases. Almost all bug reports need to include at least the versions of salt and its
|
||||
dependencies, the system type and version, commands used, debug logs, error messages, and relevant configs.
|
||||
- ``Info Needed`` - The issue needs more information before it can be verified
|
||||
and resolved. For a feature request this may include a description of the
|
||||
use cases. Almost all bug reports need to include at least the versions of
|
||||
salt and its dependencies, the system type and version, commands used, debug
|
||||
logs, error messages, and relevant configs.
|
||||
|
||||
``Pending Changes``
|
||||
The pull request needs additional changes before it can be merged.
|
||||
- ``Pending Changes`` - The pull request needs additional changes before it can
|
||||
be merged.
|
||||
|
||||
``Pending Discussion``
|
||||
The issue or pull request needs more discussion before it can be closed or merged. The status of the issue or pull
|
||||
request is not clear or apparent enough for definite action to be taken, or additional input from SaltStack, the
|
||||
submitter, or another party has been requested.
|
||||
- ``Pending Discussion`` - The issue or pull request needs more discussion
|
||||
before it can be closed or merged. The status of the issue or pull request
|
||||
is not clear or apparent enough for definite action to be taken, or
|
||||
additional input from SaltStack, the submitter, or another party has been
|
||||
requested.
|
||||
|
||||
If the issue is not a pull request, once the discussion has arrived at a cogent conclusion, this label will be
|
||||
removed and the issue will be accepted. If it is a pull request, the results of the discussion may require
|
||||
additional changes and thus, a ``Pending Changes`` label.
|
||||
If the issue is not a pull request, once the discussion has arrived at a
|
||||
cogent conclusion, this label will be removed and the issue will be accepted.
|
||||
If it is a pull request, the results of the discussion may require additional
|
||||
changes and thus, a ``Pending Changes`` label.
|
||||
|
||||
``Won't Fix for Now``
|
||||
The issue is legitimate, but it is not something the SaltStack team is currently able or willing to fix or
|
||||
implement. Issues having this label may be revisited in the future.
|
||||
- ``Won't Fix for Now`` - The issue is legitimate, but it is not something the
|
||||
SaltStack team is currently able or willing to fix or implement. Issues
|
||||
having this label may be revisited in the future.
|
||||
|
||||
Type of Change
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Every pull request should receive a change label. These labels measure the quantity of change as well as the
|
||||
significance of the change. The amount of change and the importance of the code area changed are considered, but often
|
||||
the depth of secondary code review required and the potential repercussions of the change may also advise the label
|
||||
choice.
|
||||
Every pull request should receive a change label. These labels measure the
|
||||
quantity of change as well as the significance of the change. The amount of
|
||||
change and the importance of the code area changed are considered, but often
|
||||
the depth of secondary code review required and the potential repercussions of
|
||||
the change may also advise the label choice.
|
||||
|
||||
Core code areas include: state compiler, crypto engine, master and minion and syndic daemons, transport, pillar
|
||||
rendering, loader, transport layer, event system, salt.utils, client, cli, logging, netapi, runner engine, templating
|
||||
engine, top file compilation, file client, file server, mine, salt-ssh, test runner, etc.
|
||||
Core code areas include: state compiler, crypto engine, master and minion and
|
||||
syndic daemons, transport, pillar rendering, loader, transport layer, event
|
||||
system, salt.utils, client, cli, logging, netapi, runner engine, templating
|
||||
engine, top file compilation, file client, file server, mine, salt-ssh, test
|
||||
runner, etc.
|
||||
|
||||
Non-core code usually constitutes the specific set of plugins for each of the several plugin layers of Salt: execution
|
||||
modules, states, runners, returners, clouds, etc.
|
||||
Non-core code usually constitutes the specific set of plugins for each of the
|
||||
several plugin layers of Salt: execution modules, states, runners, returners,
|
||||
clouds, etc.
|
||||
|
||||
``Minor Change``
|
||||
* Less than 64 lines changed, or
|
||||
* Less than 8 core lines changed
|
||||
``Medium Change``
|
||||
* Less than 256 lines changed, or
|
||||
* Less than 64 core lines changed
|
||||
``Master Change``
|
||||
* More than 256 lines changed, or
|
||||
* More than 64 core lines changed
|
||||
``Expert Change``
|
||||
* Needs specialized, in-depth review
|
||||
- ``Minor Change``
|
||||
|
||||
* Less than 64 lines changed, or
|
||||
|
||||
* Less than 8 core lines changed
|
||||
|
||||
- ``Medium Change``
|
||||
|
||||
* Less than 256 lines changed, or
|
||||
|
||||
* Less than 64 core lines changed
|
||||
|
||||
- ``Master Change``
|
||||
|
||||
* More than 256 lines changed, or
|
||||
|
||||
* More than 64 core lines changed
|
||||
|
||||
- ``Expert Change``
|
||||
|
||||
* Needs specialized, in-depth review
|
||||
|
||||
Test Status
|
||||
-----------
|
||||
|
||||
These labels relate to the status of the automated tests that run on pull requests. If the tests on a pull request fail
|
||||
and are not overridden by one of these labels, the pull request submitter needs to update the code and/or tests so that
|
||||
the tests pass and the pull request can be merged.
|
||||
These labels relate to the status of the automated tests that run on pull
|
||||
requests. If the tests on a pull request fail and are not overridden by one of
|
||||
these labels, the pull request submitter needs to update the code and/or tests
|
||||
so that the tests pass and the pull request can be merged.
|
||||
|
||||
``Lint``
|
||||
The pull request has passed all tests except for the code lint checker.
|
||||
- ``Lint`` - The pull request has passed all tests except for the code lint
|
||||
checker.
|
||||
|
||||
``Tests Passed``
|
||||
The pull request has passed all tests even though some test results are negative. Sometimes the automated testing
|
||||
infrastructure will encounter internal errors unrelated to the code change in the pull request that cause test runs
|
||||
to fail. These errors can be caused by cloud host and network issues and also Jenkins issues like erroneously
|
||||
accumulating workspace artifacts, resource exhaustion, and bugs that arise from long running Jenkins processes.
|
||||
- ``Tests Passed`` - The pull request has passed all tests even though some
|
||||
test results are negative. Sometimes the automated testing infrastructure
|
||||
will encounter internal errors unrelated to the code change in the pull
|
||||
request that cause test runs to fail. These errors can be caused by cloud
|
||||
host and network issues and also Jenkins issues like erroneously accumulating
|
||||
workspace artifacts, resource exhaustion, and bugs that arise from long
|
||||
running Jenkins processes.
|
||||
|
||||
Other
|
||||
-----
|
||||
|
||||
These labels indicate miscellaneous issue types or statuses that are common or important enough to be tracked and sorted
|
||||
with labels.
|
||||
These labels indicate miscellaneous issue types or statuses that are common or
|
||||
important enough to be tracked and sorted with labels.
|
||||
|
||||
``Awesome``
|
||||
The pull request implements an especially well crafted solution, or a very difficult but necessary change.
|
||||
- ``Awesome`` - The pull request implements an especially well crafted
|
||||
solution, or a very difficult but necessary change.
|
||||
|
||||
``Help Wanted``
|
||||
The issue appears to have a simple solution. Issues having this label
|
||||
should be a good starting place for new contributors to Salt.
|
||||
- ``Help Wanted`` - The issue appears to have a simple solution. Issues having
|
||||
this label should be a good starting place for new contributors to Salt.
|
||||
|
||||
``Needs Testcase``
|
||||
The issue or pull request relates to a feature that needs test coverage. The pull request containing the tests
|
||||
should reference the issue or pull request having this label, whereupon the label should be removed.
|
||||
- ``Needs Testcase`` - The issue or pull request relates to a feature that
|
||||
needs test coverage. The pull request containing the tests should reference
|
||||
the issue or pull request having this label, whereupon the label should be
|
||||
removed.
|
||||
|
||||
``Regression``
|
||||
The issue is a bug that breaks functionality known to work in previous releases.
|
||||
- ``Regression`` - The issue is a bug that breaks functionality known to work
|
||||
in previous releases.
|
||||
|
||||
``Story``
|
||||
The issue is used by a SaltStack engineer to track progress on multiple related issues in a single place.
|
||||
- ``Story`` - The issue is used by a SaltStack engineer to track progress on
|
||||
multiple related issues in a single place.
|
||||
|
||||
``Stretch``
|
||||
The issue is an optional goal for the current sprint but may not be delivered.
|
||||
- ``Stretch`` - The issue is an optional goal for the current sprint but may
|
||||
not be delivered.
|
||||
|
||||
``ZD``
|
||||
The issue is related to a Zendesk customer support ticket.
|
||||
- ``ZD`` - The issue is related to a Zendesk customer support ticket.
|
||||
|
||||
``<Release>``
|
||||
The issue is scheduled to be implemented by ``<Release>``. See :ref:`<version-numbers>` for a
|
||||
discussion of Salt's release codenames.
|
||||
- ``<Release>`` - The issue is scheduled to be implemented by ``<Release>``.
|
||||
See :ref:`here <version-numbers>` for a discussion of Salt's release
|
||||
codenames.
|
||||
|
||||
@ -34,7 +34,7 @@ Clone
|
||||
In your CLI, navigate to the directory into which you want clone the Salt
|
||||
codebase and submit the following command:
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
$ git clone https://github.com/<my_account>/salt.git
|
||||
|
||||
@ -42,7 +42,7 @@ where ``<my_account>`` is the name of your GitHub account. After the clone has
|
||||
completed, add SaltStack as a second remote and fetch any changes from
|
||||
``upstream``.
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
$ cd salt
|
||||
$ git remote add upstream https://github.com/saltstack/salt.git
|
||||
@ -53,7 +53,7 @@ the default branch for the SaltStack GitHub project. This branch needs to
|
||||
track ``upstream/develop`` so that we will get all upstream changes when they
|
||||
happen.
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
$ git checkout develop
|
||||
$ git branch --set-upstream-to upstream/develop
|
||||
@ -65,7 +65,7 @@ Fetch
|
||||
Fetch any ``upstream`` changes on the ``develop`` branch and sync them to your
|
||||
local copy of the branch with a single command:
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
$ git pull --rebase
|
||||
|
||||
@ -87,7 +87,7 @@ updated. I'll select the ``alternatives`` module.
|
||||
Create a new branch off from ``develop``. Be sure to name it something short
|
||||
and descriptive.
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
$ git checkout -b virt_ret
|
||||
|
||||
@ -97,10 +97,13 @@ Edit
|
||||
|
||||
Edit the file you have selected, and verify that the changes are correct.
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
$ vim salt/modules/alternatives.py
|
||||
$ git diff
|
||||
|
||||
.. code-block:: diff
|
||||
|
||||
diff --git a/salt/modules/alternatives.py b/salt/modules/alternatives.py
|
||||
index 1653e5f..30c0a59 100644
|
||||
--- a/salt/modules/alternatives.py
|
||||
@ -122,7 +125,7 @@ Commit
|
||||
Stage and commit the changes. Write a descriptive commit summary, but try to
|
||||
keep it less than 50 characters. Review your commit.
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
$ git add salt/modules/alternatives.py
|
||||
$ git commit -m 'modules.alternatives: __virtual__ return err msg'
|
||||
@ -143,7 +146,7 @@ Push
|
||||
Push your branch to your GitHub account. You will likely need to enter your
|
||||
GitHub username and password.
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push origin virt_ret
|
||||
Username for 'https://github.com': <my_account>
|
||||
@ -156,7 +159,7 @@ GitHub username and password.
|
||||
you have done this, you may need add the keys to your git repository
|
||||
configuration
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
$ git config ssh.key ~/.ssh/<key_name>
|
||||
|
||||
|
||||
@ -124,9 +124,9 @@ Writing Grains
|
||||
The grains are derived by executing all of the "public" functions (i.e. those
|
||||
which do not begin with an underscore) found in the modules located in the
|
||||
Salt's core grains code, followed by those in any custom grains modules. The
|
||||
functions in a grains module must return a Python :ref:`dict
|
||||
<python2:typesmapping>`, where the dictionary keys are the names of grains, and
|
||||
each key's value is that value for that grain.
|
||||
functions in a grains module must return a :ref:`Python dictionary
|
||||
<typesmapping>`, where the dictionary keys are the names of grains, and each
|
||||
key's value is that value for that grain.
|
||||
|
||||
Custom grains modules should be placed in a subdirectory named ``_grains``
|
||||
located under the :conf_master:`file_roots` specified by the master config
|
||||
|
||||
@ -119,9 +119,9 @@ can use the `Freenode webchat client`_ right from your browser.
|
||||
|
||||
`Logs of the IRC channel activity`_ are being collected courtesy of Moritz Lenz.
|
||||
|
||||
.. _Freenode:: http://freenode.net/irc_servers.shtml
|
||||
.. _Freenode webchat client:: http://webchat.freenode.net/?channels=salt&uio=Mj10cnVlJjk9dHJ1ZSYxMD10cnVl83
|
||||
.. _Logs of the IRC channel activity:: http://irclog.perlgeek.de/salt/
|
||||
.. _Freenode: http://freenode.net/irc_servers.shtml
|
||||
.. _`Freenode webchat client`: http://webchat.freenode.net/?channels=salt&uio=Mj10cnVlJjk9dHJ1ZSYxMD10cnVl83
|
||||
.. _`Logs of the IRC channel activity`: http://irclog.perlgeek.de/salt/
|
||||
|
||||
If you wish to discuss the development of Salt itself join us in
|
||||
``#salt-devel``.
|
||||
|
||||
@ -5,13 +5,14 @@ FreeBSD
|
||||
Installation
|
||||
============
|
||||
|
||||
Salt is available in the FreeBSD ports at `sysutils/py-salt. <https://www.freshports.org/sysutils/py-salt/>`__
|
||||
Salt is available in the FreeBSD ports tree at `sysutils/py-salt
|
||||
<https://www.freshports.org/sysutils/py-salt/>`_.
|
||||
|
||||
|
||||
FreeBSD binary repo
|
||||
===================
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
pkg install py27-salt
|
||||
|
||||
@ -20,13 +21,13 @@ FreeBSD ports
|
||||
|
||||
By default salt is packaged using python 2.7, but if you build your own packages from FreeBSD ports either by hand or with poudriere you can instead package it with your choice of python. Add a line to /etc/make.conf to choose your python flavour:
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: text
|
||||
|
||||
echo "DEFAULT_VERSIONS+= python=3.6" >> /etc/make.conf
|
||||
|
||||
Then build the port and install:
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
cd /usr/ports/sysutils/py-salt
|
||||
make install
|
||||
@ -38,7 +39,7 @@ Post-installation tasks
|
||||
|
||||
Copy the sample configuration file:
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
cp /usr/local/etc/salt/master.sample /usr/local/etc/salt/master
|
||||
|
||||
@ -46,7 +47,7 @@ Copy the sample configuration file:
|
||||
|
||||
Activate the Salt Master in ``/etc/rc.conf``:
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
sysrc salt_master_enable="YES"
|
||||
|
||||
@ -54,7 +55,7 @@ Activate the Salt Master in ``/etc/rc.conf``:
|
||||
|
||||
Start the Salt Master as follows:
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
service salt_master start
|
||||
|
||||
@ -62,7 +63,7 @@ Start the Salt Master as follows:
|
||||
|
||||
Copy the sample configuration file:
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
cp /usr/local/etc/salt/minion.sample /usr/local/etc/salt/minion
|
||||
|
||||
@ -70,7 +71,7 @@ Copy the sample configuration file:
|
||||
|
||||
Activate the Salt Minion in ``/etc/rc.conf``:
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
sysrc salt_minion_enable="YES"
|
||||
|
||||
@ -78,7 +79,7 @@ Activate the Salt Minion in ``/etc/rc.conf``:
|
||||
|
||||
Start the Salt Minion as follows:
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
service salt_minion start
|
||||
|
||||
|
||||
@ -142,7 +142,7 @@ Optional Dependencies
|
||||
settings)
|
||||
* gcc - dynamic `Cython`_ module compiling
|
||||
|
||||
.. _`Python 2.6`: http://python.org/download/
|
||||
.. _`Python 2.7`: http://python.org/download/
|
||||
.. _`ZeroMQ`: http://zeromq.org/
|
||||
.. _`pyzmq`: https://github.com/zeromq/pyzmq
|
||||
.. _`msgpack-python`: https://pypi.python.org/pypi/msgpack-python/
|
||||
|
||||
@ -64,7 +64,7 @@ populated with values from the existing config, but they will be grayed out.
|
||||
There will also be a checkbox to use the existing config. If you continue, the
|
||||
existing config will be used. If the checkbox is unchecked, default values are
|
||||
displayed and can be changed. If you continue, the existing config file in
|
||||
``c:\salt\conf`` will be removed along with the ``c:\salt\conf\minion.d`
|
||||
``c:\salt\conf`` will be removed along with the ``c:\salt\conf\minion.d``
|
||||
directory. The values entered will be used with the default config.
|
||||
|
||||
The final page allows you to start the minion service and optionally change its
|
||||
|
||||
@ -4,14 +4,13 @@
|
||||
Understanding Jinja
|
||||
===================
|
||||
|
||||
`Jinja <http://jinja.pocoo.org/docs/>`_ is the default templating language
|
||||
in SLS files.
|
||||
`Jinja`_ is the default templating language in SLS files.
|
||||
|
||||
.. _Jinja: http://jinja.pocoo.org/docs/templates/
|
||||
|
||||
Jinja in States
|
||||
===============
|
||||
|
||||
.. _Jinja: http://jinja.pocoo.org/docs/templates/
|
||||
|
||||
Jinja is evaluated before YAML, which means it is evaluated before the States
|
||||
are run.
|
||||
|
||||
@ -176,10 +175,9 @@ Saltstack extends `builtin filters`_ with these custom filters:
|
||||
``strftime``
|
||||
------------
|
||||
|
||||
Converts any time related object into a time based string. It requires a
|
||||
valid :ref:`strftime directives <python2:strftime-strptime-behavior>`. An
|
||||
:ref:`exhaustive list <python2:strftime-strptime-behavior>` can be found in
|
||||
the official Python documentation.
|
||||
Converts any time related object into a time based string. It requires valid
|
||||
strftime directives. An exhaustive list can be found :ref:`here
|
||||
<strftime-strptime-behavior>` in the Python documentation.
|
||||
|
||||
.. code-block:: jinja
|
||||
|
||||
@ -1805,7 +1803,7 @@ Logs
|
||||
Yes, in Salt, one is able to debug a complex Jinja template using the logs.
|
||||
For example, making the call:
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
{%- do salt.log.error('testing jinja logging') -%}
|
||||
|
||||
|
||||
@ -38,8 +38,8 @@ simply by creating a data structure. (And this is exactly how much of Salt's
|
||||
own internals work!)
|
||||
|
||||
.. autoclass:: salt.netapi.NetapiClient
|
||||
:members: local, local_async, local_subset, ssh, ssh_async,
|
||||
runner, runner_async, wheel, wheel_async
|
||||
:members: local, local_async, local_subset, ssh, runner, runner_async,
|
||||
wheel, wheel_async
|
||||
|
||||
.. toctree::
|
||||
|
||||
|
||||
@ -21,8 +21,8 @@ New in Carbon (2016.11)
|
||||
-----------------------
|
||||
|
||||
The methodologies for network automation have been introduced in
|
||||
:ref:`Carbon <release-2016-11-0.network-automation-napalm>` based on proxy
|
||||
minions:
|
||||
:ref:`2016.11.0 <release-2016-11-0-network-automation-napalm>`. Network
|
||||
automation support is based on proxy minions.
|
||||
|
||||
- :mod:`NAPALM proxy <salt.proxy.napalm>`
|
||||
- :mod:`Junos proxy<salt.proxy.junos>`
|
||||
|
||||
@ -235,7 +235,7 @@ To get a more dynamic state, use jinja variables together with
|
||||
Using the same example but passing on pillar data, the state would be like
|
||||
this.
|
||||
|
||||
.. code-block:: yaml
|
||||
.. code-block:: jinja
|
||||
|
||||
# /srv/salt/orch/deploy.sls
|
||||
{% set servers = salt['pillar.get']('servers', 'test') %}
|
||||
|
||||
@ -141,7 +141,7 @@ targeting to them via a top file will have the key of ``company`` with a value
|
||||
of ``Foo Industries``.
|
||||
|
||||
Consequently this data can be used from within modules, renderers, State SLS
|
||||
files, and more via the shared pillar :ref:`dict <python2:typesmapping>`:
|
||||
files, and more via the shared pillar dictionary:
|
||||
|
||||
.. code-block:: jinja
|
||||
|
||||
|
||||
@ -54,7 +54,7 @@ connection with the remote device only when required.
|
||||
New in 2016.11.0
|
||||
----------------
|
||||
|
||||
Proxy minions now support configuration files with names ending in '*.conf'
|
||||
Proxy minions now support configuration files with names ending in '\*.conf'
|
||||
and placed in /etc/salt/proxy.d.
|
||||
|
||||
Proxy minions can now be configured in /etc/salt/proxy or /etc/salt/proxy.d
|
||||
@ -387,8 +387,9 @@ Pre 2015.8 the proxymodule also must have an ``id()`` function. 2015.8 and foll
|
||||
this function because the proxy's id is required on the command line.
|
||||
|
||||
Here is an example proxymodule used to interface to a *very* simple REST
|
||||
server. Code for the server is in the `salt-contrib GitHub repository
|
||||
<https://github.com/saltstack/salt-contrib/tree/master/proxyminion_rest_example>`_
|
||||
server. Code for the server is in the `salt-contrib GitHub repository`_.
|
||||
|
||||
.. _`salt-contrib GitHub repository`: https://github.com/saltstack/salt-contrib/tree/master/proxyminion_rest_example
|
||||
|
||||
This proxymodule enables "service" enumeration, starting, stopping, restarting,
|
||||
and status; "package" installation, and a ping.
|
||||
@ -738,7 +739,7 @@ This sections specifically talks about the SSH proxy module and
|
||||
explains the working of the example proxy module ``ssh_sample``.
|
||||
|
||||
Here is a simple example proxymodule used to interface to a device over SSH.
|
||||
Code for the SSH shell is in the `salt-contrib GitHub repository <https://github.com/saltstack/salt-contrib/proxyminion_ssh_example>`_
|
||||
Code for the SSH shell is in the `salt-contrib GitHub repository`_.
|
||||
|
||||
This proxymodule enables "package" installation.
|
||||
|
||||
|
||||
@ -47,8 +47,6 @@ You can find the source code for Salt on my GitHub page, I have also set up a
|
||||
few wiki pages explaining how to use and set up Salt. If you are using Arch
|
||||
Linux there is a package available in the Arch Linux AUR.
|
||||
|
||||
Salt 0.6.0 Source: :download:`salt-0.6.0.tar.gz`
|
||||
|
||||
GitHub page: |saltrepo|
|
||||
|
||||
Wiki: https://github.com/saltstack/salt/wiki
|
||||
|
||||
@ -50,12 +50,8 @@ to Matthias Teege for tracking down some configuration bugs!
|
||||
|
||||
Salt can be downloaded from the following locations;
|
||||
|
||||
Source Tarball:
|
||||
|
||||
:download:`salt-0.7.0.tar.gz`
|
||||
|
||||
Arch Linux Package:
|
||||
|
||||
https://aur.archlinux.org/packages/salt-git/
|
||||
|
||||
Please enjoy the latest Salt release!
|
||||
Please enjoy the latest Salt release!
|
||||
|
||||
@ -5,8 +5,6 @@ Salt 0.8.0 release notes
|
||||
Salt 0.8.0 is ready for general consumption!
|
||||
The source tarball is available on GitHub for download:
|
||||
|
||||
:download:`salt-0.8.0.tar.gz`
|
||||
|
||||
A lot of work has gone into salt since the last release just 2 weeks ago, and
|
||||
salt has improved a great deal. A swath of new features are here along with
|
||||
performance and threading improvements!
|
||||
|
||||
@ -13,7 +13,6 @@ but the back end to support expansion is in place.
|
||||
|
||||
I also recently gave a presentation to the Utah Python users group in Salt Lake
|
||||
City, the slides from this presentation are available here:
|
||||
:download:`Salt.pdf`
|
||||
|
||||
The video from this presentation will be available shortly.
|
||||
|
||||
@ -74,7 +73,5 @@ making debugging of minion modules MUCH easier.
|
||||
Salt is nearing the goal of 1.0, where the core feature set and capability is
|
||||
complete!
|
||||
|
||||
Salt 0.8.7 can be downloaded from GitHub here:
|
||||
:download:`salt-0.8.7.tar.gz`
|
||||
|
||||
-Thomas S Hatch
|
||||
-Thomas S Hatch
|
||||
|
||||
@ -3,8 +3,7 @@ Salt 0.8.8 release notes
|
||||
========================
|
||||
|
||||
Salt 0.8.8 is here! This release adds a great deal of code and some serious new
|
||||
features. The latest release can be downloaded here:
|
||||
:download:`salt-0.8.8.tar.gz`
|
||||
features.
|
||||
|
||||
Improved Documentation has been set up for salt using sphinx thanks to the
|
||||
efforts of Seth House. This new documentation system will act as the back end
|
||||
@ -73,6 +72,5 @@ maintaining supreme usability and simplicity.
|
||||
If you would like a more complete overview of Salt please watch the Salt
|
||||
presentation:
|
||||
Slides:
|
||||
:download:`Salt.pdf`
|
||||
|
||||
-Thomas S Hatch
|
||||
-Thomas S Hatch
|
||||
|
||||
@ -17,11 +17,7 @@ date has been filled in.
|
||||
Download!
|
||||
---------
|
||||
|
||||
The Salt source can be downloaded from the salt GitHub site:
|
||||
|
||||
:download:`salt-0.8.9.tar.gz`
|
||||
|
||||
Or from PyPI:
|
||||
The Salt source can be downloaded from PyPI:
|
||||
|
||||
https://pypi.python.org/packages/source/s/salt/salt-0.8.9.tar.gz
|
||||
|
||||
|
||||
@ -14,11 +14,7 @@ improvements to the ZeroMQ systems.
|
||||
Download!
|
||||
---------
|
||||
|
||||
The Salt source can be downloaded from the salt GitHub site:
|
||||
|
||||
:download:`salt-0.9.0.tar.gz`
|
||||
|
||||
Or from PyPI:
|
||||
The Salt source can be downloaded from PyPI:
|
||||
|
||||
https://pypi.python.org/packages/source/s/salt/salt-0.9.0.tar.gz
|
||||
|
||||
@ -124,4 +120,4 @@ Extensive utilities for managing processes
|
||||
publish
|
||||
~~~~~~~
|
||||
|
||||
Used by the peer interface to allow minions to make publications
|
||||
Used by the peer interface to allow minions to make publications
|
||||
|
||||
@ -17,11 +17,7 @@ helping us clean up the states interface and make it ready for the world!
|
||||
Download!
|
||||
---------
|
||||
|
||||
The Salt source can be downloaded from the salt GitHub site:
|
||||
|
||||
:download:`salt-0.9.2.tar.gz`
|
||||
|
||||
Or from PyPI:
|
||||
The Salt source can be downloaded from PyPI:
|
||||
|
||||
https://pypi.python.org/packages/source/s/salt/salt-0.9.2.tar.gz
|
||||
|
||||
@ -77,4 +73,4 @@ Cython Loading Disabled by Default
|
||||
Cython loading requires a development tool chain to be installed on the minion,
|
||||
requiring this by default can cause problems for most Salt deployments. If
|
||||
Cython auto loading is desired it will need to be turned on in the minion
|
||||
config.
|
||||
config.
|
||||
|
||||
@ -16,11 +16,7 @@ system has been greatly refined and many new features are available.
|
||||
Download!
|
||||
---------
|
||||
|
||||
The Salt source can be downloaded from the salt GitHub site:
|
||||
|
||||
:download:`salt-0.9.3.tar.gz`
|
||||
|
||||
Or from PyPI:
|
||||
The Salt source can be downloaded from PyPI:
|
||||
|
||||
https://pypi.python.org/packages/source/s/salt/salt-0.9.3.tar.gz
|
||||
|
||||
|
||||
@ -18,11 +18,7 @@ our new and existing contributors.
|
||||
Download!
|
||||
=========
|
||||
|
||||
The Salt source can be downloaded from the salt GitHub site:
|
||||
|
||||
:download:`salt-0.9.4.tar.gz`
|
||||
|
||||
Or from PyPI:
|
||||
The Salt source can be downloaded from PyPI:
|
||||
|
||||
https://pypi.python.org/packages/source/s/salt/salt-0.9.4.tar.gz
|
||||
|
||||
@ -145,4 +141,4 @@ Gentoo Support
|
||||
--------------
|
||||
|
||||
Additional experimental support has been added for Gentoo. This is found in
|
||||
the contribution from Doug Renn, aka nestegg.
|
||||
the contribution from Doug Renn, aka nestegg.
|
||||
|
||||
@ -4,7 +4,7 @@ Salt 2014.7.1 Release Notes
|
||||
|
||||
:release: 2015-01-12
|
||||
|
||||
Version 2014.7.1 is a bugfix release for :ref:`2014.7.0<release-2014-7-0>`.
|
||||
Version 2014.7.1 is a bugfix release for :ref:`2014.7.0 <release-2014-7-0>`.
|
||||
|
||||
The changes include:
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user