mirror of
https://github.com/saltstack/salt.git
synced 2025-04-17 10:10:20 +00:00
Merge branch '2018.3' into 'develop'
Conflicts: - doc/topics/installation/freebsd.rst - salt/cloud/clouds/oneandone.py - salt/grains/core.py - salt/modules/napalm_ntp.py - salt/modules/win_update.py - salt/modules/win_wua.py - salt/modules/zabbix.py - salt/renderers/pass.py - salt/states/vault.py - tests/unit/states/test_win_update.py
This commit is contained in:
commit
7dc1e770c4
792 changed files with 54831 additions and 29602 deletions
|
@ -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
|
||||
|
|
13
doc/conf.py
13
doc/conf.py
|
@ -106,6 +106,7 @@ MOCK_MODULES = [
|
|||
|
||||
'tornado',
|
||||
'tornado.concurrent',
|
||||
'tornado.escape',
|
||||
'tornado.gen',
|
||||
'tornado.httpclient',
|
||||
'tornado.httpserver',
|
||||
|
@ -137,8 +138,8 @@ MOCK_MODULES = [
|
|||
'pymongo',
|
||||
'rabbitmq_server',
|
||||
'redis',
|
||||
'requests',
|
||||
'requests.exceptions',
|
||||
#'requests',
|
||||
#'requests.exceptions',
|
||||
'rpm',
|
||||
'rpmUtils',
|
||||
'rpmUtils.arch',
|
||||
|
@ -237,8 +238,7 @@ formulas_dir = os.path.join(os.pardir, docs_basepath, 'formulas')
|
|||
|
||||
# ----- Intersphinx Settings ------------------------------------------------>
|
||||
intersphinx_mapping = {
|
||||
'python2': ('http://docs.python.org/2', None),
|
||||
'python3': ('http://docs.python.org/3', None)
|
||||
'python': ('https://docs.python.org/3', None)
|
||||
}
|
||||
# <---- Intersphinx Settings -------------------------------------------------
|
||||
|
||||
|
@ -357,9 +357,8 @@ rst_prolog = """\
|
|||
# A shortcut for linking to tickets on the GitHub issue tracker
|
||||
extlinks = {
|
||||
'blob': ('https://github.com/saltstack/salt/blob/%s/%%s' % 'develop', None),
|
||||
'download': ('https://cloud.github.com/downloads/saltstack/salt/%s', None),
|
||||
'issue': ('https://github.com/saltstack/salt/issues/%s', 'issue '),
|
||||
'pull': ('https://github.com/saltstack/salt/pull/%s', 'PR '),
|
||||
'issue': ('https://github.com/saltstack/salt/issues/%s', 'issue #'),
|
||||
'pull': ('https://github.com/saltstack/salt/pull/%s', 'PR #'),
|
||||
'formula_url': ('https://github.com/saltstack-formulas/%s', ''),
|
||||
}
|
||||
|
||||
|
|
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
@ -502,5 +503,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:
|
||||
|
|
|
@ -30,7 +30,7 @@ Execution Module Used for
|
|||
:py:mod:`~salt.modules.solarispkg` Solaris-based OSes using ``pkgadd(1M)``
|
||||
:py:mod:`~salt.modules.solarisips` Solaris-based OSes using IPS ``pkg(1)``
|
||||
:py:mod:`~salt.modules.win_pkg` Salt's :ref:`Windows Package Manager
|
||||
<windows-package-manager`
|
||||
<windows-package-manager>`
|
||||
:py:mod:`~salt.modules.yumpkg` RedHat-based distros and derivatives
|
||||
using ``yum(8)`` or ``dnf(8)``
|
||||
:py:mod:`~salt.modules.zypper` SUSE-based distros using ``zypper(8)``
|
||||
|
|
|
@ -33,7 +33,3 @@ Execution Module Used for
|
|||
:py:mod:`~salt.modules.win_service` Windows
|
||||
====================================== ========================================
|
||||
|
||||
|
|
||||
|
||||
.. automodule:: salt.modules.service
|
||||
:members:
|
||||
|
|
|
@ -18,9 +18,3 @@ Execution Module Used for
|
|||
:py:mod:`~salt.modules.solaris_shadow` Solaris-based OSes
|
||||
:py:mod:`~salt.modules.win_shadow` Windows
|
||||
====================================== ========================================
|
||||
|
||||
|
|
||||
|
||||
.. automodule:: salt.modules.shadow
|
||||
:members:
|
||||
|
||||
|
|
|
@ -137,7 +137,7 @@ call functions available in other execution modules.
|
|||
The variable ``__salt__`` is packed into the modules after they are loaded into
|
||||
the Salt minion.
|
||||
|
||||
The ``__salt__`` variable is a :ref:`Python dictionary <python2:typesmapping>`
|
||||
The ``__salt__`` variable is a :ref:`Python dictionary <typesmapping>`
|
||||
containing all of the Salt functions. Dictionary keys are strings representing
|
||||
the names of the modules and the values are the functions themselves.
|
||||
|
||||
|
@ -157,6 +157,7 @@ Calling Execution Modules on the Salt Master
|
|||
============================================
|
||||
|
||||
.. versionadded:: 2016.11.0
|
||||
|
||||
Execution modules can now also be called via the :command:`salt-run` command
|
||||
using the :ref:`salt runner <salt_salt_runner>`.
|
||||
|
||||
|
@ -175,8 +176,8 @@ Grains Data
|
|||
-----------
|
||||
|
||||
The values detected by the Salt Grains on the minion are available in a
|
||||
:ref:`dict <python2:typesmapping>` named ``__grains__`` and can be accessed
|
||||
from within callable objects in the Python modules.
|
||||
:ref:`Python dictionary <typesmapping>` named ``__grains__`` and can be
|
||||
accessed from within callable objects in the Python modules.
|
||||
|
||||
To see the contents of the grains dictionary for a given system in your
|
||||
deployment run the :func:`grains.items` function:
|
||||
|
@ -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'])
|
||||
|
|
|
@ -326,4 +326,5 @@ state modules
|
|||
zk_concurrency
|
||||
zfs
|
||||
zone
|
||||
zookeeper
|
||||
zpool
|
||||
|
|
|
@ -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,4 +1,4 @@
|
|||
======------============
|
||||
========================
|
||||
salt.states.rbac_solaris
|
||||
========================
|
||||
|
||||
|
|
|
@ -1,3 +1,5 @@
|
|||
.. _compiler-ordering:
|
||||
|
||||
=====================================
|
||||
Understanding State Compiler Ordering
|
||||
=====================================
|
||||
|
|
|
@ -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:
|
||||
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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``.
|
||||
|
|
|
@ -11,7 +11,7 @@ Salt is available in the FreeBSD ports at `sysutils/py-salt. <https://www.freshp
|
|||
FreeBSD binary repo
|
||||
===================
|
||||
|
||||
.. code-block:: shell
|
||||
.. code-block:: bash
|
||||
|
||||
pkg install py27-salt
|
||||
|
||||
|
@ -20,13 +20,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 +38,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 +46,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 +54,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 +62,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 +70,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 +78,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:
|
||||
|
||||
|
|
|
@ -2,9 +2,9 @@
|
|||
Salt 2014.7.3 Release Notes
|
||||
===========================
|
||||
|
||||
:release: TBA
|
||||
:release: 2015-03-25
|
||||
|
||||
Version 2014.7.3 is a bugfix release for :ref:`2014.7.0<release-2014-7-0>`.
|
||||
Version 2014.7.3 is a bugfix release for :ref:`2014.7.0 <release-2014-7-0>`.
|
||||
|
||||
Changes:
|
||||
|
||||
|
|
|
@ -4,7 +4,7 @@ Salt 2014.7.4 Release Notes
|
|||
|
||||
:release: 2015-03-30
|
||||
|
||||
Version 2014.7.4 is a bugfix release for :ref:`2014.7.0<release-2014-7-0>`.
|
||||
Version 2014.7.4 is a bugfix release for :ref:`2014.7.0 <release-2014-7-0>`.
|
||||
|
||||
This is a security release. The security issues fixed have only been present
|
||||
since 2014.7.0, and only users of the two listed modules are vulnerable. The
|
||||
|
|
|
@ -4,7 +4,7 @@ Salt 2014.7.5 Release Notes
|
|||
|
||||
:release: 2015-04-16
|
||||
|
||||
Version 2014.7.5 is a bugfix release for :ref:`2014.7.0<release-2014-7-0>`.
|
||||
Version 2014.7.5 is a bugfix release for :ref:`2014.7.0 <release-2014-7-0>`.
|
||||
|
||||
Changes:
|
||||
|
||||
|
|
File diff suppressed because it is too large
Load diff
624
doc/topics/releases/2014.7.7.rst
Normal file
624
doc/topics/releases/2014.7.7.rst
Normal file
|
@ -0,0 +1,624 @@
|
|||
===========================
|
||||
Salt 2014.7.7 Release Notes
|
||||
===========================
|
||||
|
||||
:release: 2015-10-13
|
||||
|
||||
Version 2014.7.7 is a bugfix release for :ref:`2014.7.0 <release-2014-7-0>`.
|
||||
|
||||
Statistics
|
||||
==========
|
||||
|
||||
- Total Merges: **54**
|
||||
- Total Issue References: **20**
|
||||
- Total PR References: **60**
|
||||
|
||||
- Contributors: **28** (`AkhterAli`_, `BretFisher`_, `MrCitron`_, `alekti`_, `basepi`_, `bersace`_, `cachedout`_, `corux`_, `cro`_, `davidjb`_, `dumol`_, `efficks`_, `garethgreenaway`_, `hvnsweeting`_, `jacksontj`_, `jacobhammons`_, `jaybocc2`_, `jfindlay`_, `jquast`_, `justinta`_, `msteed`_, `nmadhok`_, `notpeter`_, `puneetk`_, `rallytime`_, `techhat`_, `trevor-h`_, `twangboy`_)
|
||||
|
||||
|
||||
Changelog for v2014.7.6..v2014.7.7
|
||||
==================================
|
||||
|
||||
*Generated at: 2018-05-27 20:45:04 UTC*
|
||||
|
||||
* **PR** `#27335`_: (`rallytime`_) [2014.7] Fixup salt-cloud logging
|
||||
@ *2015-09-24 20:33:53 UTC*
|
||||
|
||||
* 5262f01325 Merge pull request `#27335`_ from rallytime/cloud-logging-7
|
||||
|
||||
* adeb1dcad4 Pylint Fix
|
||||
|
||||
* 588c13783c Salt-cloud logging clean up for windows functions
|
||||
|
||||
* 9b6000135c [2014.7] Fixup salt-cloud logging
|
||||
|
||||
* **PR** `#27252`_: (`jfindlay`_) 2014.7 -> 2014.7.0
|
||||
@ *2015-09-18 23:44:39 UTC*
|
||||
|
||||
* e90412d3b8 Merge pull request `#27252`_ from jfindlay/version.2014.7
|
||||
|
||||
* 3d28307a00 2014.7 -> 2014.7.0
|
||||
|
||||
* **PR** `#27117`_: (`jacobhammons`_) made 2014.7 an archived release
|
||||
@ *2015-09-15 07:35:12 UTC*
|
||||
|
||||
* c186e51764 Merge pull request `#27117`_ from jacobhammons/release-docs-2014.7
|
||||
|
||||
* b69e11e0a4 made 2014.7 an archived release minor doc site updates
|
||||
|
||||
* **PR** `#27114`_: (`cachedout`_) Issue warning that some log levels may contain sensitive data
|
||||
@ *2015-09-15 07:30:43 UTC*
|
||||
|
||||
* 69d758ee2b Merge pull request `#27114`_ from cachedout/warn_on_insecure_log
|
||||
|
||||
* 507fb04683 Issue warning that some log levels may contain sensitive data
|
||||
|
||||
* **PR** `#27075`_: (`twangboy`_) Replaced password with redacted when displayed
|
||||
@ *2015-09-14 18:36:10 UTC*
|
||||
|
||||
* aa71bae8aa Merge pull request `#27075`_ from twangboy/fix_password_2014.7
|
||||
|
||||
* c0689e3215 Replaced password with redacted when displayed
|
||||
|
||||
* **ISSUE** `#26656`_: (`ari`_) [documentation] error in example for salt.runner.pillar (refs: `#26667`_)
|
||||
|
||||
* **PR** `#26667`_: (`nmadhok`_) [doc-fix] Removing special character from salt.runners.pillar and other changes
|
||||
@ *2015-08-26 18:24:37 UTC*
|
||||
|
||||
* c2c7fe06c8 Merge pull request `#26667`_ from nmadhok/doc-fix-2014.7
|
||||
|
||||
* 26be189689 Doc fix. Fixes `#26656`_
|
||||
|
||||
* **PR** `#26663`_: (`jacobhammons`_) version change for latest branch
|
||||
@ *2015-08-26 14:03:35 UTC*
|
||||
|
||||
* 6bd3dccae8 Merge pull request `#26663`_ from jacobhammons/2014.7-version
|
||||
|
||||
* b6af538070 version change for latest branch
|
||||
|
||||
* **PR** `#26636`_: (`rallytime`_) Refactor cloud provider tests to be more accurate
|
||||
@ *2015-08-25 21:28:34 UTC*
|
||||
|
||||
* 071a6112e5 Merge pull request `#26636`_ from rallytime/cloud-test-fixes
|
||||
|
||||
* c0d83d558d Don't use id as variable
|
||||
|
||||
* 2b4bc1679d Keep ec2 instance creation test the same - it works better for the ec2 output
|
||||
|
||||
* b5b58eb31f Skip digital ocean tests since we can't use API v1 with v2 tests
|
||||
|
||||
* 9ae1539c62 Update cloud tests to be more efficient and accurate
|
||||
|
||||
* **ISSUE** `#26630`_: (`efficks`_) win_service: Function has_powershell does not works on Windows XP (refs: `#26640`_)
|
||||
|
||||
* **PR** `#26640`_: (`efficks`_) Fix function spacing
|
||||
@ *2015-08-25 20:01:39 UTC*
|
||||
|
||||
* 304542b4c6 Merge pull request `#26640`_ from efficks/fixws2014
|
||||
|
||||
* ebe5d9d85c Fix function spacing
|
||||
|
||||
* **PR** `#26515`_: (`bersace`_) Defaults to current saltenv in state.sls
|
||||
@ *2015-08-25 16:35:50 UTC*
|
||||
|
||||
* 4532f98a76 Merge pull request `#26515`_ from bersace/salt-env-local-sls
|
||||
|
||||
* 0727af9e3d Defaults to current saltenv in state.sls
|
||||
|
||||
* **PR** `#26242`_: (`cro`_) Remove dead code
|
||||
@ *2015-08-12 15:14:20 UTC*
|
||||
|
||||
* da8bca09aa Merge pull request `#26242`_ from cro/anonldap4
|
||||
|
||||
* a0d2ab1eed Remove dead code
|
||||
|
||||
* **PR** `#26216`_: (`cro`_) Fix LDAP configuration issue.
|
||||
@ *2015-08-11 18:33:43 UTC*
|
||||
|
||||
* 1ecf23773e Merge pull request `#26216`_ from cro/anonldap3
|
||||
|
||||
* af132d7b89 Documentation update for anonymous bind issue.
|
||||
|
||||
* 2ef54b6b13 Documentation update for anonymous bind issue.
|
||||
|
||||
* 5b1836bb00 Fix issue with LDAP anonymous binds.
|
||||
|
||||
* **PR** `#26116`_: (`corux`_) file.replace fails if repl string is an invalid regex and append/prepend is used
|
||||
@ *2015-08-10 16:44:12 UTC*
|
||||
|
||||
* abdf2935c4 Merge pull request `#26116`_ from corux/fix-escape-content
|
||||
|
||||
* fd913ddc36 Append/prepend: search for full line with escaped content
|
||||
|
||||
* **ISSUE** `#25751`_: (`basepi`_) Document `master_finger` more prominently (refs: `#26088`_)
|
||||
|
||||
* **PR** `#26088`_: (`jacobhammons`_) Master finger
|
||||
@ *2015-08-07 14:31:33 UTC*
|
||||
|
||||
* 106356d98d Merge pull request `#26088`_ from jacobhammons/master-finger
|
||||
|
||||
* 133d5f7885 some small changes
|
||||
|
||||
* d220c83f77 master_finger configuration docs switch a script to use https:// instead of http:// Refs `#25751`_
|
||||
|
||||
* **ISSUE** `#25961`_: (`getabc`_) [2015.5.3-2] salt-winrepo.git/salt-minion.sls fails certificate '\*.wpengine.com' or 'wpengine.com' (refs: `#26047`_)
|
||||
|
||||
* **PR** `#26047`_: (`jacobhammons`_) Updated windows download links in the docs to https://repo.saltstack.com
|
||||
@ *2015-08-05 22:59:44 UTC*
|
||||
|
||||
* 4bd4bc41f2 Merge pull request `#26047`_ from jacobhammons/win-downloads
|
||||
|
||||
* 7c162d181c Updated windows download links in the docs to https://repo.saltstack.com Refs `#25961`_
|
||||
|
||||
* **ISSUE** `#25701`_: (`alekti`_) Issue `#23764`_ regression (refs: `#25750`_)
|
||||
|
||||
* **ISSUE** `#23764`_: (`es1o`_) source_hash from local file is not supported. (refs: `#25750`_)
|
||||
|
||||
* **PR** `#25750`_: (`alekti`_) Add file as supported protocol for file source_hash. Fixes `#25701`_.
|
||||
@ *2015-07-29 02:31:27 UTC*
|
||||
|
||||
* d93eb87c16 Merge pull request `#25750`_ from alekti/2014.7
|
||||
|
||||
* 9ec3ae96d4 Add file as supported protocol for file source_hash. Fixes `#23764`_.
|
||||
|
||||
* **PR** `#25704`_: (`cachedout`_) Ensure prior alignment with master_type in 2014.7
|
||||
@ *2015-07-27 16:06:35 UTC*
|
||||
|
||||
* 3a15df22ac Merge pull request `#25704`_ from cachedout/master_type_2014_7
|
||||
|
||||
* c95886c9a7 Ensure prior alignment with master_type in 2014.7
|
||||
|
||||
* **PR** `#25657`_: (`MrCitron`_) Add the ability to specify a base pattern for carbon returner
|
||||
@ *2015-07-24 16:32:58 UTC*
|
||||
|
||||
* d1b9362a73 Merge pull request `#25657`_ from MrCitron/pattern-carbon-returner-2014.7
|
||||
|
||||
* f8b2f8079f Add the ability to specify a base pattern for metrics path used by the carbon returner
|
||||
|
||||
* **PR** `#25633`_: (`AkhterAli`_) Update loader.py
|
||||
@ *2015-07-22 20:02:41 UTC*
|
||||
|
||||
* 9634351fc2 Merge pull request `#25633`_ from AkhterAli/2014.7
|
||||
|
||||
* 29be4bbe11 Update loader.py
|
||||
|
||||
* **PR** `#25416`_: (`cachedout`_) Fix broken keyword
|
||||
@ *2015-07-14 19:47:10 UTC*
|
||||
|
||||
* 09ebaceca8 Merge pull request `#25416`_ from cachedout/str_2014_7
|
||||
|
||||
* cc514938a8 Fix broken keyword
|
||||
|
||||
* **PR** `#25375`_: (`cachedout`_) Fix error in config.py for master_type
|
||||
@ *2015-07-13 16:49:27 UTC*
|
||||
|
||||
* 2a1dd1113f Merge pull request `#25375`_ from cachedout/config_fix_2014_7
|
||||
|
||||
* c041f2905f Fix error in config.py for master_type
|
||||
|
||||
* **PR** `#25324`_: (`jacobhammons`_) Latest help theme updates
|
||||
@ *2015-07-10 16:11:31 UTC*
|
||||
|
||||
* 2590e23d48 Merge pull request `#25324`_ from jacobhammons/doc-theme-updates
|
||||
|
||||
* 88f5fcf58d Latest help theme updates
|
||||
|
||||
* **ISSUE** `#18447`_: (`ryan-lane`_) Can't install salt with raet using pip -e git (refs: `#25093`_)
|
||||
|
||||
* **PR** `#25093`_: (`jaybocc2`_) quick fix for issue `#18447`_
|
||||
@ *2015-07-01 15:56:53 UTC*
|
||||
|
||||
* 36d53ef59e Merge pull request `#25093`_ from jaybocc2/2014.7
|
||||
|
||||
* c6a501ebda quick fix for issue `#18447`_
|
||||
|
||||
* **PR** `#25069`_: (`puneetk`_) Add a helper module function called list_enabled
|
||||
@ *2015-06-30 20:53:51 UTC*
|
||||
|
||||
* 38903a94a1 Merge pull request `#25069`_ from puneetk/patch-1
|
||||
|
||||
* f0b4e600e6 Update Documentation to clarify version added
|
||||
|
||||
* f8dc6030e7 Pylint updates , removing whitespace
|
||||
|
||||
* 532d315dd1 [Code Review update] renamed function to is_enaled from list_enabled
|
||||
|
||||
* 20b0462289 Update schedule.py
|
||||
|
||||
* 4f1471d7fb Add a helper module function called list_enabled
|
||||
|
||||
* **ISSUE** `#15209`_: (`hubez`_) file.manage: source_hash not working with s3:// (2014.7.0rc1) (refs: `#25011`_)
|
||||
|
||||
* **PR** `#25011`_: (`notpeter`_) Add s3 to protocols for remote source_hash (2014.7 backport)
|
||||
@ *2015-06-27 22:35:44 UTC*
|
||||
|
||||
* a7154e7471 Merge pull request `#25011`_ from notpeter/s3_2014.7_backport
|
||||
|
||||
* 8b8af640f6 Add s3 to protocols for remote source_hash
|
||||
|
||||
* **ISSUE** `#24915`_: (`justinta`_) Salt-cloud not working in 2014.7.6 (refs: `#24944`_)
|
||||
|
||||
* **PR** `#24944`_: (`techhat`_) Double-check main_cloud_config
|
||||
@ *2015-06-25 12:29:55 UTC*
|
||||
|
||||
* a11e4c6eea Merge pull request `#24944`_ from techhat/issue24915
|
||||
|
||||
* 59c3081e49 Double-check main_cloud_config
|
||||
|
||||
* **PR** `#24936`_: (`justinta`_) Fixed ps module to not use depreciated psutil commands
|
||||
@ *2015-06-24 22:38:19 UTC*
|
||||
|
||||
* d26a5447ba Merge pull request `#24936`_ from jtand/psutil
|
||||
|
||||
* bdb7a19c36 Fixed ps module to not use depreciated psutil commands
|
||||
|
||||
* **ISSUE** `saltstack/salt-bootstrap#473`_: (`s1kbr0`_) salt-bootstrap.sh [...] git v2014.1.11 on SmartOS base64 is broken (refs: `#24918`_)
|
||||
|
||||
* **PR** `#24918`_: (`BretFisher`_) SmartOS SMF minion startup fix
|
||||
@ *2015-06-24 15:44:26 UTC*
|
||||
|
||||
* eeb05a1b10 Merge pull request `#24918`_ from BretFisher/minion-start-smartos-smf-fix
|
||||
|
||||
* d7bfb0c7fd Smartos smf minion fix
|
||||
|
||||
* **ISSUE** `#24776`_: (`nmadhok`_) --static option in salt raises ValueError and has been broken for a very long time (refs: `#24777`_)
|
||||
|
||||
* **PR** `#24780`_: (`nmadhok`_) Backporting PR `#24777`_ to 2014.7 branch
|
||||
@ *2015-06-18 14:52:56 UTC*
|
||||
|
||||
* **PR** `#24779`_: (`nmadhok`_) Backporting Changes to 2014.7 branch (refs: `#24777`_)
|
||||
|
||||
* **PR** `#24778`_: (`nmadhok`_) Backporting PR `#24777`_ to 2015.2 branch (refs: `#24777`_)
|
||||
|
||||
* **PR** `#24777`_: (`nmadhok`_) Fixing issue where --static option fails with ValueError Fixes `#24776`_ (refs: `#24778`_, `#24780`_)
|
||||
|
||||
* 4281dfff0b Merge pull request `#24780`_ from nmadhok/backport-2014.7-24777
|
||||
|
||||
* c53b0d9a22 Backporting PR `#24777`_ to 2014.7 branch
|
||||
|
||||
* **ISSUE** `#21318`_: (`thanatos`_) get_full_returns raises KeyError (refs: `#24769`_)
|
||||
|
||||
* **ISSUE** `#18994`_: (`njhartwell`_) salt.client.get_cli_returns errors when called immediately after run_job (refs: `#24769`_)
|
||||
|
||||
* **PR** `#24769`_: (`msteed`_) Fix stacktrace in get_cli_returns()
|
||||
@ *2015-06-18 14:31:46 UTC*
|
||||
|
||||
* f3c5cb2d41 Merge pull request `#24769`_ from msteed/issue-21318
|
||||
|
||||
* f40a9d5cc0 Fix stacktrace in get_cli_returns()
|
||||
|
||||
* **ISSUE** `#17041`_: (`xenophonf`_) Confusing Salt error messages due to limited/incomplete PowerShell command error handling (refs: `#24690`_)
|
||||
|
||||
* **PR** `#24690`_: (`twangboy`_) Report powershell output instead of error
|
||||
@ *2015-06-17 16:33:49 UTC*
|
||||
|
||||
* 59db24602f Merge pull request `#24690`_ from twangboy/fix_17041
|
||||
|
||||
* 7a015389af Added additional reporting
|
||||
|
||||
* d84ad5d519 Fixed capitalization... Failed and Already
|
||||
|
||||
* e9552455c4 Merge branch '2014.7' of https://github.com/saltstack/salt into fix_17041
|
||||
|
||||
* **ISSUE** `#24196`_: (`johnccfm`_) Exception when using user.present with Windows (refs: `#24646`_)
|
||||
|
||||
* **PR** `#24646`_: (`twangboy`_) Fixed user.present on existing user
|
||||
@ *2015-06-15 15:04:43 UTC*
|
||||
|
||||
* a18dadad71 Merge pull request `#24646`_ from twangboy/fix_24196
|
||||
|
||||
* a208e1d60f Fixed user.present on existing user
|
||||
|
||||
* 144bff2f67 Report powershell output instead of error
|
||||
|
||||
* **PR** `#24643`_: (`cro`_) Add reference to salt-announce mailing list
|
||||
@ *2015-06-12 20:21:15 UTC*
|
||||
|
||||
* b99484fde2 Merge pull request `#24643`_ from cro/saltannounce
|
||||
|
||||
* ecb0623d7f Add salt-announce mailing list.
|
||||
|
||||
* **PR** `#24620`_: (`twangboy`_) Fixed comment and uncomment functions in file.py
|
||||
@ *2015-06-12 19:36:26 UTC*
|
||||
|
||||
* 635121e85d Merge pull request `#24620`_ from twangboy/fix_24215
|
||||
|
||||
* d7a9999be1 Fixed comment and uncomment functions in file.py
|
||||
|
||||
* **PR** `#24589`_: (`BretFisher`_) Fixed Mine example for jinja code block
|
||||
@ *2015-06-11 15:48:02 UTC*
|
||||
|
||||
* d83928a7f9 Merge pull request `#24589`_ from BretFisher/patch-1
|
||||
|
||||
* 65a11336dc Fixed Mine example for jinja code block
|
||||
|
||||
* **ISSUE** `#24427`_: (`fayetted`_) 2015.5.1-3 Windows 64Bit Minion fails to start after install (refs: `#24530`_)
|
||||
|
||||
* **PR** `#24530`_: (`twangboy`_) Start Minion Service on Silent Install
|
||||
@ *2015-06-09 21:30:08 UTC*
|
||||
|
||||
* d376390f76 Merge pull request `#24530`_ from twangboy/fix_24427
|
||||
|
||||
* 673e1d809e Added missing panel.bmp for installer
|
||||
|
||||
* cc50218b01 Start Minion Service on Silent Install
|
||||
|
||||
* **PR** `#24513`_: (`jquast`_) bugfix use of 'iteritem' in 2014.7 branch
|
||||
@ *2015-06-09 04:06:36 UTC*
|
||||
|
||||
* **PR** `#24511`_: (`jquast`_) bugfix: trailing "...done" in rabbitmq output (refs: `#24513`_)
|
||||
|
||||
* 6ebc476bb3 Merge pull request `#24513`_ from jquast/2014.7-bugfix-iteritem
|
||||
|
||||
* 2be0180e5e bugfix use of 'iteritem' in 2014.7 branch
|
||||
|
||||
* **ISSUE** `#24276`_: (`markuskramerIgitt`_) Live salt-master Profiling with SIGUSR2 fails (refs: `#24405`_)
|
||||
|
||||
* **PR** `#24405`_: (`jacksontj`_) Fix for `#24276`_
|
||||
@ *2015-06-04 20:50:42 UTC*
|
||||
|
||||
* 83f853b6ea Merge pull request `#24405`_ from jacksontj/2014.7
|
||||
|
||||
* 2c7afaeebf Fix for `#24276`_
|
||||
|
||||
* **PR** `#24395`_: (`hvnsweeting`_) handle exceptions when received data is not in good shape
|
||||
@ *2015-06-04 20:08:22 UTC*
|
||||
|
||||
* cef919c602 Merge pull request `#24395`_ from hvnsweeting/handle-exception-get-file
|
||||
|
||||
* bb798a0224 handle exceptions when received data is not in good shape
|
||||
|
||||
* **PR** `#24305`_: (`twangboy`_) Added documentation, fixed formatting
|
||||
@ *2015-06-04 19:40:54 UTC*
|
||||
|
||||
* efba1a94b4 Merge pull request `#24305`_ from twangboy/win_path_docs
|
||||
|
||||
* 36804253e6 Fixed pylint error caused by \P... added r
|
||||
|
||||
* bc42a4bb11 triple double quotes to triple single quotes
|
||||
|
||||
* 77cd930bba Added documentation, fixed formatting
|
||||
|
||||
* **PR** `#24178`_: (`rallytime`_) Backport `#24118`_ to 2014.7, too.
|
||||
@ *2015-05-27 17:49:45 UTC*
|
||||
|
||||
* **PR** `#24118`_: (`trevor-h`_) removed deprecated pymongo usage (refs: `#24178`_)
|
||||
|
||||
* 9d7331c87d Merge pull request `#24178`_ from rallytime/bp-24118
|
||||
|
||||
* e2217a09e8 removed deprecated pymongo usage as no longer functional with pymongo > 3.x
|
||||
|
||||
* **PR** `#24159`_: (`rallytime`_) Fill out modules/keystone.py CLI Examples
|
||||
@ *2015-05-27 15:07:11 UTC*
|
||||
|
||||
* 4e8c5031b0 Merge pull request `#24159`_ from rallytime/keystone_doc_examples
|
||||
|
||||
* dadac8d076 Fill out modules/keystone.py CLI Examples
|
||||
|
||||
* **PR** `#24158`_: (`rallytime`_) Fix test_valid_docs test for tls module
|
||||
@ *2015-05-27 15:06:05 UTC*
|
||||
|
||||
* fc10ee8ed5 Merge pull request `#24158`_ from rallytime/fix_doc_error
|
||||
|
||||
* 49a517e2ca Fix test_valid_docs test for tls module
|
||||
|
||||
* **PR** `#24125`_: (`hvnsweeting`_) Fix rabbitmq test mode
|
||||
@ *2015-05-26 15:40:18 UTC*
|
||||
|
||||
* c0d32e0b5e Merge pull request `#24125`_ from hvnsweeting/fix-rabbitmq-test-mode
|
||||
|
||||
* 71862c69b9 enhance log
|
||||
|
||||
* 28e2594162 change according to new output of rabbitmq module functions
|
||||
|
||||
* cd0212e8ed processes and returns better output for rabbitmq module
|
||||
|
||||
* **ISSUE** `#23464`_: (`tibold`_) cmd_iter_no_block() blocks (refs: `#24093`_)
|
||||
|
||||
* **PR** `#24093`_: (`msteed`_) Make LocalClient.cmd_iter_no_block() not block
|
||||
@ *2015-05-25 15:56:42 UTC*
|
||||
|
||||
* 39a8f30f06 Merge pull request `#24093`_ from msteed/issue-23464
|
||||
|
||||
* fd35903d75 Fix failing test
|
||||
|
||||
* 41b344c7d3 Make LocalClient.cmd_iter_no_block() not block
|
||||
|
||||
* **PR** `#24008`_: (`davidjb`_) Correct reST formatting for states.cmd documentation
|
||||
@ *2015-05-21 04:19:01 UTC*
|
||||
|
||||
* 5bffd3045e Merge pull request `#24008`_ from davidjb/2014.7
|
||||
|
||||
* 8b8d0293d4 Correct reST formatting for documentation
|
||||
|
||||
* **PR** `#23933`_: (`jacobhammons`_) sphinx saltstack2 doc theme
|
||||
@ *2015-05-20 18:19:19 UTC*
|
||||
|
||||
* 1aa0420040 Merge pull request `#23933`_ from jacobhammons/2014.7
|
||||
|
||||
* a3613e68e4 removed numbering from doc TOC
|
||||
|
||||
* 78b737c5e6 removed 2015.* release from release notes, updated index page to remove PDF/epub links
|
||||
|
||||
* e867f7df77 Changed build settings to use saltstack2 theme and update release versions.
|
||||
|
||||
* 81ed9c9f59 sphinx saltstack2 doc theme
|
||||
|
||||
* **PR** `#23965`_: (`hvnsweeting`_) handle all exceptions gitpython can raise
|
||||
@ *2015-05-20 15:08:03 UTC*
|
||||
|
||||
* 314e4db512 Merge pull request `#23965`_ from hvnsweeting/20147-fix-gitfs-gitpython-exception
|
||||
|
||||
* 2576301631 handle all exception gitpython can raise
|
||||
|
||||
* **PR** `#23939`_: (`basepi`_) Add extended changelog to 2014.7.6 release notes
|
||||
@ *2015-05-19 21:21:00 UTC*
|
||||
|
||||
* 913391207a Merge pull request `#23939`_ from basepi/v2014.7.6release
|
||||
|
||||
* 32b65dc2a9 Add extended changelog to 2014.7.6 release notes
|
||||
|
||||
* **ISSUE** `#23820`_: (`UtahDave`_) 2014.7.5 schedule error (refs: `#23881`_)
|
||||
|
||||
* **PR** `#23881`_: (`garethgreenaway`_) Fixes to schedule module in 2014.7
|
||||
@ *2015-05-19 15:46:30 UTC*
|
||||
|
||||
* 0031ca2631 Merge pull request `#23881`_ from garethgreenaway/23820_2014_7_schedule_list_issue
|
||||
|
||||
* b207f2a433 Missing continue in the list function when deleting unused attributes.
|
||||
|
||||
* **ISSUE** `#22131`_: (`quixoten`_) "unexpected keyword argument 'merge'" on 2014.7.2 (salt-ssh) (refs: `#23887`_)
|
||||
|
||||
* **PR** `#23887`_: (`basepi`_) [2014.7] Bring salt-ssh pillar.get in line with mainline pillar.get
|
||||
@ *2015-05-18 23:11:34 UTC*
|
||||
|
||||
* 63bd21ecd2 Merge pull request `#23887`_ from basepi/salt-ssh.pillar.get.22131
|
||||
|
||||
* bc84502f46 Bring salt-ssh pillar.get in line with mainline pillar.get
|
||||
|
||||
* **PR** `#23891`_: (`basepi`_) Update the release notes index page
|
||||
@ *2015-05-18 23:06:52 UTC*
|
||||
|
||||
* 17c5810c04 Merge pull request `#23891`_ from basepi/releasenotes
|
||||
|
||||
* dec153bcea Update the release notes index page
|
||||
|
||||
* **PR** `#23888`_: (`basepi`_) Update the 2014.7.6 release notes with CVE details
|
||||
@ *2015-05-18 22:35:51 UTC*
|
||||
|
||||
* a93e58f80f Merge pull request `#23888`_ from basepi/v2014.7.6release
|
||||
|
||||
* 49921b6cb2 Update the 2014.7.6 release notes with CVE details
|
||||
|
||||
* **PR** `#23871`_: (`rallytime`_) Backport `#23848`_ to 2014.7
|
||||
@ *2015-05-18 20:34:04 UTC*
|
||||
|
||||
* **PR** `#23848`_: (`dumol`_) Updated installation docs for SLES 12. (refs: `#23871`_)
|
||||
|
||||
* 50730287bb Merge pull request `#23871`_ from rallytime/bp-23848
|
||||
|
||||
* 379c09c3a5 Updated for SLES 12.
|
||||
|
||||
.. _`#15209`: https://github.com/saltstack/salt/issues/15209
|
||||
.. _`#17041`: https://github.com/saltstack/salt/issues/17041
|
||||
.. _`#18447`: https://github.com/saltstack/salt/issues/18447
|
||||
.. _`#18994`: https://github.com/saltstack/salt/issues/18994
|
||||
.. _`#21318`: https://github.com/saltstack/salt/issues/21318
|
||||
.. _`#22131`: https://github.com/saltstack/salt/issues/22131
|
||||
.. _`#23464`: https://github.com/saltstack/salt/issues/23464
|
||||
.. _`#23764`: https://github.com/saltstack/salt/issues/23764
|
||||
.. _`#23820`: https://github.com/saltstack/salt/issues/23820
|
||||
.. _`#23848`: https://github.com/saltstack/salt/pull/23848
|
||||
.. _`#23871`: https://github.com/saltstack/salt/pull/23871
|
||||
.. _`#23881`: https://github.com/saltstack/salt/pull/23881
|
||||
.. _`#23887`: https://github.com/saltstack/salt/pull/23887
|
||||
.. _`#23888`: https://github.com/saltstack/salt/pull/23888
|
||||
.. _`#23891`: https://github.com/saltstack/salt/pull/23891
|
||||
.. _`#23933`: https://github.com/saltstack/salt/pull/23933
|
||||
.. _`#23939`: https://github.com/saltstack/salt/pull/23939
|
||||
.. _`#23965`: https://github.com/saltstack/salt/pull/23965
|
||||
.. _`#24008`: https://github.com/saltstack/salt/pull/24008
|
||||
.. _`#24093`: https://github.com/saltstack/salt/pull/24093
|
||||
.. _`#24118`: https://github.com/saltstack/salt/pull/24118
|
||||
.. _`#24125`: https://github.com/saltstack/salt/pull/24125
|
||||
.. _`#24158`: https://github.com/saltstack/salt/pull/24158
|
||||
.. _`#24159`: https://github.com/saltstack/salt/pull/24159
|
||||
.. _`#24178`: https://github.com/saltstack/salt/pull/24178
|
||||
.. _`#24196`: https://github.com/saltstack/salt/issues/24196
|
||||
.. _`#24276`: https://github.com/saltstack/salt/issues/24276
|
||||
.. _`#24305`: https://github.com/saltstack/salt/pull/24305
|
||||
.. _`#24395`: https://github.com/saltstack/salt/pull/24395
|
||||
.. _`#24405`: https://github.com/saltstack/salt/pull/24405
|
||||
.. _`#24427`: https://github.com/saltstack/salt/issues/24427
|
||||
.. _`#24511`: https://github.com/saltstack/salt/pull/24511
|
||||
.. _`#24513`: https://github.com/saltstack/salt/pull/24513
|
||||
.. _`#24530`: https://github.com/saltstack/salt/pull/24530
|
||||
.. _`#24589`: https://github.com/saltstack/salt/pull/24589
|
||||
.. _`#24620`: https://github.com/saltstack/salt/pull/24620
|
||||
.. _`#24643`: https://github.com/saltstack/salt/pull/24643
|
||||
.. _`#24646`: https://github.com/saltstack/salt/pull/24646
|
||||
.. _`#24690`: https://github.com/saltstack/salt/pull/24690
|
||||
.. _`#24769`: https://github.com/saltstack/salt/pull/24769
|
||||
.. _`#24776`: https://github.com/saltstack/salt/issues/24776
|
||||
.. _`#24777`: https://github.com/saltstack/salt/pull/24777
|
||||
.. _`#24778`: https://github.com/saltstack/salt/pull/24778
|
||||
.. _`#24779`: https://github.com/saltstack/salt/pull/24779
|
||||
.. _`#24780`: https://github.com/saltstack/salt/pull/24780
|
||||
.. _`#24915`: https://github.com/saltstack/salt/issues/24915
|
||||
.. _`#24918`: https://github.com/saltstack/salt/pull/24918
|
||||
.. _`#24936`: https://github.com/saltstack/salt/pull/24936
|
||||
.. _`#24944`: https://github.com/saltstack/salt/pull/24944
|
||||
.. _`#25011`: https://github.com/saltstack/salt/pull/25011
|
||||
.. _`#25069`: https://github.com/saltstack/salt/pull/25069
|
||||
.. _`#25093`: https://github.com/saltstack/salt/pull/25093
|
||||
.. _`#25324`: https://github.com/saltstack/salt/pull/25324
|
||||
.. _`#25375`: https://github.com/saltstack/salt/pull/25375
|
||||
.. _`#25416`: https://github.com/saltstack/salt/pull/25416
|
||||
.. _`#25633`: https://github.com/saltstack/salt/pull/25633
|
||||
.. _`#25657`: https://github.com/saltstack/salt/pull/25657
|
||||
.. _`#25701`: https://github.com/saltstack/salt/issues/25701
|
||||
.. _`#25704`: https://github.com/saltstack/salt/pull/25704
|
||||
.. _`#25750`: https://github.com/saltstack/salt/pull/25750
|
||||
.. _`#25751`: https://github.com/saltstack/salt/issues/25751
|
||||
.. _`#25961`: https://github.com/saltstack/salt/issues/25961
|
||||
.. _`#26047`: https://github.com/saltstack/salt/pull/26047
|
||||
.. _`#26088`: https://github.com/saltstack/salt/pull/26088
|
||||
.. _`#26116`: https://github.com/saltstack/salt/pull/26116
|
||||
.. _`#26216`: https://github.com/saltstack/salt/pull/26216
|
||||
.. _`#26242`: https://github.com/saltstack/salt/pull/26242
|
||||
.. _`#26515`: https://github.com/saltstack/salt/pull/26515
|
||||
.. _`#26630`: https://github.com/saltstack/salt/issues/26630
|
||||
.. _`#26636`: https://github.com/saltstack/salt/pull/26636
|
||||
.. _`#26640`: https://github.com/saltstack/salt/pull/26640
|
||||
.. _`#26656`: https://github.com/saltstack/salt/issues/26656
|
||||
.. _`#26663`: https://github.com/saltstack/salt/pull/26663
|
||||
.. _`#26667`: https://github.com/saltstack/salt/pull/26667
|
||||
.. _`#27075`: https://github.com/saltstack/salt/pull/27075
|
||||
.. _`#27114`: https://github.com/saltstack/salt/pull/27114
|
||||
.. _`#27117`: https://github.com/saltstack/salt/pull/27117
|
||||
.. _`#27252`: https://github.com/saltstack/salt/pull/27252
|
||||
.. _`#27335`: https://github.com/saltstack/salt/pull/27335
|
||||
.. _`AkhterAli`: https://github.com/AkhterAli
|
||||
.. _`BretFisher`: https://github.com/BretFisher
|
||||
.. _`MrCitron`: https://github.com/MrCitron
|
||||
.. _`UtahDave`: https://github.com/UtahDave
|
||||
.. _`alekti`: https://github.com/alekti
|
||||
.. _`ari`: https://github.com/ari
|
||||
.. _`basepi`: https://github.com/basepi
|
||||
.. _`bersace`: https://github.com/bersace
|
||||
.. _`cachedout`: https://github.com/cachedout
|
||||
.. _`corux`: https://github.com/corux
|
||||
.. _`cro`: https://github.com/cro
|
||||
.. _`davidjb`: https://github.com/davidjb
|
||||
.. _`dumol`: https://github.com/dumol
|
||||
.. _`efficks`: https://github.com/efficks
|
||||
.. _`es1o`: https://github.com/es1o
|
||||
.. _`fayetted`: https://github.com/fayetted
|
||||
.. _`garethgreenaway`: https://github.com/garethgreenaway
|
||||
.. _`getabc`: https://github.com/getabc
|
||||
.. _`hubez`: https://github.com/hubez
|
||||
.. _`hvnsweeting`: https://github.com/hvnsweeting
|
||||
.. _`jacksontj`: https://github.com/jacksontj
|
||||
.. _`jacobhammons`: https://github.com/jacobhammons
|
||||
.. _`jaybocc2`: https://github.com/jaybocc2
|
||||
.. _`jfindlay`: https://github.com/jfindlay
|
||||
.. _`johnccfm`: https://github.com/johnccfm
|
||||
.. _`jquast`: https://github.com/jquast
|
||||
.. _`justinta`: https://github.com/justinta
|
||||
.. _`markuskramerIgitt`: https://github.com/markuskramerIgitt
|
||||
.. _`msteed`: https://github.com/msteed
|
||||
.. _`njhartwell`: https://github.com/njhartwell
|
||||
.. _`nmadhok`: https://github.com/nmadhok
|
||||
.. _`notpeter`: https://github.com/notpeter
|
||||
.. _`puneetk`: https://github.com/puneetk
|
||||
.. _`quixoten`: https://github.com/quixoten
|
||||
.. _`rallytime`: https://github.com/rallytime
|
||||
.. _`ryan-lane`: https://github.com/ryan-lane
|
||||
.. _`s1kbr0`: https://github.com/s1kbr0
|
||||
.. _`saltstack/salt-bootstrap#473`: https://github.com/saltstack/salt-bootstrap/issues/473
|
||||
.. _`techhat`: https://github.com/techhat
|
||||
.. _`thanatos`: https://github.com/thanatos
|
||||
.. _`tibold`: https://github.com/tibold
|
||||
.. _`trevor-h`: https://github.com/trevor-h
|
||||
.. _`twangboy`: https://github.com/twangboy
|
||||
.. _`xenophonf`: https://github.com/xenophonf
|
|
@ -2,76 +2,86 @@
|
|||
Salt 2014.7.8 Release Notes
|
||||
===========================
|
||||
|
||||
Changes for v2014.7.7..v2014.7.8
|
||||
--------------------------------
|
||||
:release: 2015-11-13
|
||||
|
||||
Extended changelog courtesy of Todd Stansell (https://github.com/tjstansell/salt-changelogs):
|
||||
Version 2014.7.8 is a bugfix release for :ref:`2014.7.0 <release-2014-7-0>`.
|
||||
|
||||
*Generated at: 2016-03-11T21:18:48Z*
|
||||
|
||||
Statistics:
|
||||
Statistics
|
||||
==========
|
||||
|
||||
- Total Merges: **7**
|
||||
- Total Issue references: **3**
|
||||
- Total PR references: **10**
|
||||
- Total Issue References: **3**
|
||||
- Total PR References: **10**
|
||||
|
||||
Changes:
|
||||
- Contributors: **5** (`DmitryKuzmenko`_, `JaseFace`_, `MasterNayru`_, `cachedout`_, `rallytime`_)
|
||||
|
||||
|
||||
- **PR** `#28839`_: (*cachedout*) Revert `#28740`_
|
||||
@ *2015-11-12T22:54:28Z*
|
||||
Changelog for v2014.7.7..v2014.7.8
|
||||
==================================
|
||||
|
||||
- **PR** `#28740`_: (*MasterNayru*) Add missing S3 module import
|
||||
| refs: `#28777`_
|
||||
* 4b8bdd0 Merge pull request `#28839`_ from cachedout/revert_28740
|
||||
* 215b26c Revert `#28740`_
|
||||
*Generated at: 2018-05-27 20:47:34 UTC*
|
||||
|
||||
- **PR** `#28777`_: (*rallytime*) Back-port `#28740`_ to 2014.7
|
||||
@ *2015-11-11T18:00:00Z*
|
||||
* **PR** `#28839`_: (`cachedout`_) Revert `#28740`_
|
||||
@ *2015-11-12 22:54:28 UTC*
|
||||
|
||||
- **PR** `#28740`_: (*MasterNayru*) Add missing S3 module import
|
||||
| refs: `#28777`_
|
||||
* 76e69b4 Merge pull request `#28777`_ from rallytime/`bp-28740`_-2014.7
|
||||
* da5fac2 Back-port `#28740`_ to 2014.7
|
||||
* **PR** `#28740`_: (`MasterNayru`_) Add missing S3 module import (refs: `#28777`_, `#28839`_)
|
||||
|
||||
- **PR** `#28716`_: (*rallytime*) Back-port `#28705`_ to 2014.7
|
||||
@ *2015-11-10T16:15:03Z*
|
||||
* 4b8bdd0afb Merge pull request `#28839`_ from cachedout/revert_28740
|
||||
|
||||
- **PR** `#28705`_: (*cachedout*) Account for new headers class in tornado 4.3
|
||||
| refs: `#28716`_
|
||||
* 45c73eb Merge pull request `#28716`_ from rallytime/`bp-28705`_
|
||||
* 32e7bd3 Account for new headers class in tornado 4.3
|
||||
* 215b26c06f Revert `#28740`_
|
||||
|
||||
- **PR** `#28717`_: (*cachedout*) Add note about recommended umask
|
||||
@ *2015-11-09T23:26:20Z*
|
||||
* **PR** `#28777`_: (`rallytime`_) Back-port `#28740`_ to 2014.7
|
||||
@ *2015-11-11 18:00:00 UTC*
|
||||
|
||||
- **ISSUE** `#28199`_: (*felskrone*) Non-standard umasks might break the master
|
||||
| refs: `#28717`_
|
||||
* f4fe921 Merge pull request `#28717`_ from cachedout/umask_note
|
||||
* 1874300 Add note about recommended umask
|
||||
* **PR** `#28740`_: (`MasterNayru`_) Add missing S3 module import (refs: `#28777`_, `#28839`_)
|
||||
|
||||
- **PR** `#28461`_: (*cachedout*) Wrap all cache calls in state.sls in correct umask
|
||||
@ *2015-11-02T17:11:02Z*
|
||||
* 76e69b4bff Merge pull request `#28777`_ from rallytime/bp-28740-2014.7
|
||||
|
||||
- **ISSUE** `#28455`_: (*zmalone*) highstate.cache is world readable, and contains secrets
|
||||
| refs: `#28461`_
|
||||
* 4bf56ca Merge pull request `#28461`_ from cachedout/issue_28455
|
||||
* 097838e Wrap all cache calls in state.sls in correct umask
|
||||
* da5fac2b36 Back-port `#28740`_ to 2014.7
|
||||
|
||||
- **PR** `#28407`_: (*DmitryKuzmenko*) Don't request creds if auth with key.
|
||||
@ *2015-10-29T16:12:30Z*
|
||||
* **PR** `#28716`_: (`rallytime`_) Back-port `#28705`_ to 2014.7
|
||||
@ *2015-11-10 16:15:03 UTC*
|
||||
|
||||
- **ISSUE** `#24910`_: (*bocig*) -T, --make-token flag does NOT work- LDAP Groups
|
||||
| refs: `#28407`_
|
||||
* f3e61db Merge pull request `#28407`_ from DSRCompany/issues/24910_token_auth_fix_2014
|
||||
* b7b5bec Don't request creds if auth with key.
|
||||
* **PR** `#28705`_: (`cachedout`_) Account for new headers class in tornado 4.3 (refs: `#28716`_)
|
||||
|
||||
- **PR** `#27390`_: (*JaseFace*) Ensure we pass on the enable setting if present, or use the default of True if not in build_schedule_item()
|
||||
@ *2015-10-05T18:09:33Z*
|
||||
* 45c73ebf2f Merge pull request `#28716`_ from rallytime/bp-28705
|
||||
|
||||
* d284eb1 Merge pull request `#27390`_ from JaseFace/schedule-missing-enabled
|
||||
* 563db71 Ensure we pass on the enable setting if present, or use the default of True if not in build_schedule_item() Prior to this, when schedule.present compares the existing schedule to the one crafted by this function, enabled will actually be removed at each run. schedule.present sees a modification needs to be made, and invokes schedule.modify, which does so with enabled: True, creating and endless loop of an 'enabled' removal and addition.
|
||||
* 32e7bd3ea0 Account for new headers class in tornado 4.3
|
||||
|
||||
* **ISSUE** `#28199`_: (`felskrone`_) Non-standard umasks might break the master (refs: `#28717`_)
|
||||
|
||||
* **PR** `#28717`_: (`cachedout`_) Add note about recommended umask
|
||||
@ *2015-11-09 23:26:20 UTC*
|
||||
|
||||
* f4fe921965 Merge pull request `#28717`_ from cachedout/umask_note
|
||||
|
||||
* 1874300e08 Add note about recommended umask
|
||||
|
||||
* **ISSUE** `#28455`_: (`zmalone`_) highstate.cache is world readable, and contains secrets (refs: `#28461`_)
|
||||
|
||||
* **PR** `#28461`_: (`cachedout`_) Wrap all cache calls in state.sls in correct umask
|
||||
@ *2015-11-02 17:11:02 UTC*
|
||||
|
||||
* 4bf56cad3f Merge pull request `#28461`_ from cachedout/issue_28455
|
||||
|
||||
* 097838ec0c Wrap all cache calls in state.sls in correct umask
|
||||
|
||||
* **ISSUE** `#24910`_: (`bocig`_) -T, --make-token flag does NOT work- LDAP Groups (refs: `#28407`_)
|
||||
|
||||
* **PR** `#28407`_: (`DmitryKuzmenko`_) Don't request creds if auth with key.
|
||||
@ *2015-10-29 16:12:30 UTC*
|
||||
|
||||
* f3e61db045 Merge pull request `#28407`_ from DSRCompany/issues/24910_token_auth_fix_2014
|
||||
|
||||
* b7b5bec309 Don't request creds if auth with key.
|
||||
|
||||
* **PR** `#27390`_: (`JaseFace`_) Ensure we pass on the enable setting if present, or use the default of True if not in build_schedule_item()
|
||||
@ *2015-10-05 18:09:33 UTC*
|
||||
|
||||
* d284eb165b Merge pull request `#27390`_ from JaseFace/schedule-missing-enabled
|
||||
|
||||
* 563db71bfd Ensure we pass on the enable setting if present, or use the default of True if not in build_schedule_item() Prior to this, when schedule.present compares the existing schedule to the one crafted by this function, enabled will actually be removed at each run. schedule.present sees a modification needs to be made, and invokes schedule.modify, which does so with enabled: True, creating and endless loop of an 'enabled' removal and addition.
|
||||
|
||||
.. _`#24910`: https://github.com/saltstack/salt/issues/24910
|
||||
.. _`#27390`: https://github.com/saltstack/salt/pull/27390
|
||||
|
@ -85,6 +95,11 @@ Changes:
|
|||
.. _`#28740`: https://github.com/saltstack/salt/pull/28740
|
||||
.. _`#28777`: https://github.com/saltstack/salt/pull/28777
|
||||
.. _`#28839`: https://github.com/saltstack/salt/pull/28839
|
||||
.. _`bp-28705`: https://github.com/saltstack/salt/pull/28705
|
||||
.. _`bp-28740`: https://github.com/saltstack/salt/pull/28740
|
||||
|
||||
.. _`DmitryKuzmenko`: https://github.com/DmitryKuzmenko
|
||||
.. _`JaseFace`: https://github.com/JaseFace
|
||||
.. _`MasterNayru`: https://github.com/MasterNayru
|
||||
.. _`bocig`: https://github.com/bocig
|
||||
.. _`cachedout`: https://github.com/cachedout
|
||||
.. _`felskrone`: https://github.com/felskrone
|
||||
.. _`rallytime`: https://github.com/rallytime
|
||||
.. _`zmalone`: https://github.com/zmalone
|
||||
|
|
|
@ -2,44 +2,70 @@
|
|||
Salt 2014.7.9 Release Notes
|
||||
===========================
|
||||
|
||||
Changes for v2014.7.8..v2014.7.9
|
||||
--------------------------------
|
||||
:release: 2016-03-11
|
||||
|
||||
Extended changelog courtesy of Todd Stansell (https://github.com/tjstansell/salt-changelogs):
|
||||
|
||||
*Generated at: 2016-03-11T20:58:58Z*
|
||||
|
||||
Statistics:
|
||||
|
||||
- Total Merges: **3**
|
||||
- Total Issue references: **1**
|
||||
- Total PR references: **3**
|
||||
|
||||
Changes:
|
||||
Version 2014.7.9 is a bugfix release for :ref:`2014.7.0 <release-2014-7-0>`.
|
||||
|
||||
|
||||
- **PR** `#31826`_: (*gtmanfred*) Remove ability of authenticating user to specify pam service
|
||||
@ *2016-03-11T20:41:01Z*
|
||||
Statistics
|
||||
==========
|
||||
|
||||
* c5e7c03 Merge pull request `#31826`_ from gtmanfred/2014.7
|
||||
* d73f70e Remove ability of authenticating user to specify pam service
|
||||
- Total Merges: **5**
|
||||
- Total Issue References: **1**
|
||||
- Total PR References: **5**
|
||||
|
||||
- **PR** `#29392`_: (*jacobhammons*) updated version number to not reference a specific build from the lat…
|
||||
@ *2015-12-03T15:54:31Z*
|
||||
- Contributors: **4** (`douardda`_, `gtmanfred`_, `jacobhammons`_, `jfindlay`_)
|
||||
|
||||
* 85aa70a Merge pull request `#29392`_ from jacobhammons/2014.7
|
||||
* d7f0db1 updated version number to not reference a specific build from the latest branch
|
||||
|
||||
- **PR** `#29296`_: (*douardda*) Use process KillMode on Debian systems also
|
||||
@ *2015-12-01T16:00:16Z*
|
||||
Changelog for v2014.7.8..v2014.7.9
|
||||
==================================
|
||||
|
||||
- **ISSUE** `#29295`_: (*douardda*) systemd's service file should use the 'process' KillMode option on Debian also
|
||||
| refs: `#29296`_
|
||||
* d2fb210 Merge pull request `#29296`_ from douardda/patch-3
|
||||
* d288539 Use process KillMode on Debian systems also
|
||||
*Generated at: 2018-05-27 20:55:35 UTC*
|
||||
|
||||
* **PR** `#31834`_: (`jfindlay`_) add 2014.7.8 release notes
|
||||
@ *2016-03-11 21:35:42 UTC*
|
||||
|
||||
* 218c902091 Merge pull request `#31834`_ from jfindlay/2014.7
|
||||
|
||||
* 358fdad0c8 add 2014.7.8 release notes
|
||||
|
||||
* **PR** `#31833`_: (`jfindlay`_) add 2014.7.9 release notes
|
||||
@ *2016-03-11 21:19:55 UTC*
|
||||
|
||||
* a423c6cd04 Merge pull request `#31833`_ from jfindlay/2014.7
|
||||
|
||||
* 6910fcc584 add 2014.7.9 release notes
|
||||
|
||||
* **PR** `#31826`_: (`gtmanfred`_) Remove ability of authenticating user to specify pam service
|
||||
@ *2016-03-11 20:41:01 UTC*
|
||||
|
||||
* c5e7c03953 Merge pull request `#31826`_ from gtmanfred/2014.7
|
||||
|
||||
* d73f70ebb2 Remove ability of authenticating user to specify pam service
|
||||
|
||||
* **PR** `#29392`_: (`jacobhammons`_) updated version number to not reference a specific build from the lat…
|
||||
@ *2015-12-03 15:54:31 UTC*
|
||||
|
||||
* 85aa70a6cb Merge pull request `#29392`_ from jacobhammons/2014.7
|
||||
|
||||
* d7f0db1dd8 updated version number to not reference a specific build from the latest branch
|
||||
|
||||
* **ISSUE** `#29295`_: (`douardda`_) systemd's service file should use the 'process' KillMode option on Debian also (refs: `#29296`_)
|
||||
|
||||
* **PR** `#29296`_: (`douardda`_) Use process KillMode on Debian systems also
|
||||
@ *2015-12-01 16:00:16 UTC*
|
||||
|
||||
* d2fb2109a3 Merge pull request `#29296`_ from douardda/patch-3
|
||||
|
||||
* d2885390f4 Use process KillMode on Debian systems also
|
||||
|
||||
.. _`#29295`: https://github.com/saltstack/salt/issues/29295
|
||||
.. _`#29296`: https://github.com/saltstack/salt/pull/29296
|
||||
.. _`#29392`: https://github.com/saltstack/salt/pull/29392
|
||||
.. _`#31826`: https://github.com/saltstack/salt/pull/31826
|
||||
.. _`#31833`: https://github.com/saltstack/salt/pull/31833
|
||||
.. _`#31834`: https://github.com/saltstack/salt/pull/31834
|
||||
.. _`douardda`: https://github.com/douardda
|
||||
.. _`gtmanfred`: https://github.com/gtmanfred
|
||||
.. _`jacobhammons`: https://github.com/jacobhammons
|
||||
.. _`jfindlay`: https://github.com/jfindlay
|
||||
|
|
File diff suppressed because it is too large
Load diff
|
@ -2,10 +2,15 @@
|
|||
Salt 2015.5.10 Release Notes
|
||||
============================
|
||||
|
||||
:release: 2015-03-22
|
||||
|
||||
Version 2015.5.10 is a bugfix release for :ref:`2015.5.0 <release-2015-5-0>`.
|
||||
|
||||
|
||||
Security Fix
|
||||
============
|
||||
|
||||
CVE-2016-3176: Insecure configuration of PAM external authentication service
|
||||
**CVE-2016-3176** Insecure configuration of PAM external authentication service
|
||||
|
||||
This issue affects all Salt versions prior to 2015.8.8/2015.5.10 when PAM
|
||||
:ref:`external authentication <acl-eauth>` is enabled. This issue involves
|
||||
|
@ -17,7 +22,7 @@ for bringing this issue to our attention.
|
|||
This update defines the PAM eAuth ``service`` that users authenticate against
|
||||
in the Salt Master configuration.
|
||||
|
||||
(No additional fixes are contained in this release).
|
||||
No additional fixes are included in this release.
|
||||
|
||||
Read Before Upgrading Debian 8 (Jessie) from Salt Versions Earlier than 2015.5.9
|
||||
================================================================================
|
||||
|
@ -32,3 +37,10 @@ Salt ``systemd`` service files are missing the following statement in these vers
|
|||
This statement must be added to successfully upgrade on these earlier versions
|
||||
of Salt.
|
||||
|
||||
|
||||
Changelog for v2015.5.9..v2015.5.10
|
||||
===================================
|
||||
|
||||
*Generated at: 2018-05-27 22:39:26 UTC*
|
||||
|
||||
* 69ba1de71d Remove ability of authenticating user to specify pam service
|
||||
|
|
File diff suppressed because it is too large
Load diff
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Reference in a new issue