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:
rallytime 2018-06-06 13:35:36 -04:00
commit 7dc1e770c4
No known key found for this signature in database
GPG key ID: E8F1A4B90D0DEA19
792 changed files with 54831 additions and 29602 deletions

View file

@ -1,7 +1,7 @@
#!/usr/bin/env python
# -*- coding: utf-8 -*-
'''
:codeauthor: :email:`Pedro Algarvio (pedro@algarvio.me)`
:codeauthor: Pedro Algarvio (pedro@algarvio.me)
compile-translation-catalogs

View file

@ -1,7 +1,7 @@
#!/usr/bin/env python
# -*- coding: utf-8 -*-
'''
:codeauthor: :email:`Pedro Algarvio (pedro@algarvio.me)`
:codeauthor: Pedro Algarvio (pedro@algarvio.me)
download-translation-catalog

View file

@ -1,7 +1,7 @@
#!/usr/bin/env python
# -*- coding: utf-8 -*-
'''
:codeauthor: :email:`Pedro Algarvio (pedro@algarvio.me)`
:codeauthor: Pedro Algarvio (pedro@algarvio.me)
setup-transifex-config

View file

@ -1,7 +1,7 @@
#!/usr/bin/env python
# -*- coding: utf-8 -*-
'''
:codeauthor: :email:`Pedro Algarvio (pedro@algarvio.me)`
:codeauthor: Pedro Algarvio (pedro@algarvio.me)
update-transifex-source-translations

View file

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

View file

@ -106,6 +106,7 @@ MOCK_MODULES = [
'tornado',
'tornado.concurrent',
'tornado.escape',
'tornado.gen',
'tornado.httpclient',
'tornado.httpserver',
@ -137,8 +138,8 @@ MOCK_MODULES = [
'pymongo',
'rabbitmq_server',
'redis',
'requests',
'requests.exceptions',
#'requests',
#'requests.exceptions',
'rpm',
'rpmUtils',
'rpmUtils.arch',
@ -237,8 +238,7 @@ formulas_dir = os.path.join(os.pardir, docs_basepath, 'formulas')
# ----- Intersphinx Settings ------------------------------------------------>
intersphinx_mapping = {
'python2': ('http://docs.python.org/2', None),
'python3': ('http://docs.python.org/3', None)
'python': ('https://docs.python.org/3', None)
}
# <---- Intersphinx Settings -------------------------------------------------
@ -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', ''),
}

View file

@ -7,6 +7,7 @@ Salt Table of Contents
.. toctree::
:maxdepth: 2
topics/index
topics/installation/index
topics/configuration/index
topics/using_salt
@ -15,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

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.1 KiB

View file

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

View file

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

View file

@ -1,5 +1,5 @@
salt.cache.consul module
========================
salt.cache.consul
=================
.. automodule:: salt.cache.consul
:members:

View file

@ -1,5 +1,5 @@
salt.cache.etcd_cache module
=============================
salt.cache.etcd_cache
=====================
.. automodule:: salt.cache.etcd_cache
:members:

View file

@ -1,5 +1,5 @@
salt.cache.localfs module
=========================
salt.cache.localfs
==================
.. automodule:: salt.cache.localfs
:members:

View file

@ -1,5 +1,5 @@
salt.cache.mysql_cache module
=============================
salt.cache.mysql_cache
======================
.. automodule:: salt.cache.mysql_cache
:members:

View file

@ -1,5 +1,5 @@
salt.cache.redis_cache module
=============================
salt.cache.redis_cache
======================
.. automodule:: salt.cache.redis_cache
:members:

View file

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

View file

@ -46,14 +46,6 @@ Options
Instead of waiting for the job to run on minions only print the job id of
the started execution and complete.
.. option:: --state-output=STATE_OUTPUT
.. versionadded:: 0.17
Override the configured ``state_output`` value for minion output. One of
``full``, ``terse``, ``mixed``, ``changes`` or ``filter``. Default:
``full``.
.. option:: --subset=SUBSET
Execute the routine on a random subset of the targeted minions. The

View file

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

View file

@ -23,6 +23,7 @@ cloud modules
lxc
msazure
nova
oneandone
opennebula
openstack
parallels

View file

@ -1,6 +1,6 @@
===============================
========================
salt.cloud.clouds.aliyun
===============================
========================
.. automodule:: salt.cloud.clouds.aliyun
:members:
:members:

View file

@ -1,5 +1,6 @@
salt.cloud.clouds.vultrpy module
================================
=========================
salt.cloud.clouds.vultrpy
=========================
.. automodule:: salt.cloud.clouds.vultrpy
:members:

View file

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

View file

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

View file

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

View file

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

View file

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

View file

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

View file

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

View file

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

View file

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

View file

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

View file

@ -1,6 +1,6 @@
===================
=====================
salt.modules.opsgenie
===================
=====================
.. automodule:: salt.modules.opsgenie
:members:

View file

@ -30,7 +30,7 @@ Execution Module Used for
:py:mod:`~salt.modules.solarispkg` Solaris-based OSes using ``pkgadd(1M)``
:py:mod:`~salt.modules.solarisips` Solaris-based OSes using IPS ``pkg(1)``
:py:mod:`~salt.modules.win_pkg` Salt's :ref:`Windows Package Manager
<windows-package-manager`
<windows-package-manager>`
:py:mod:`~salt.modules.yumpkg` RedHat-based distros and derivatives
using ``yum(8)`` or ``dnf(8)``
:py:mod:`~salt.modules.zypper` SUSE-based distros using ``zypper(8)``

View file

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

View file

@ -18,9 +18,3 @@ Execution Module Used for
:py:mod:`~salt.modules.solaris_shadow` Solaris-based OSes
:py:mod:`~salt.modules.win_shadow` Windows
====================================== ========================================
|
.. automodule:: salt.modules.shadow
:members:

View file

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

View file

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

View file

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

View file

@ -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'])

View file

@ -326,4 +326,5 @@ state modules
zk_concurrency
zfs
zone
zookeeper
zpool

View file

@ -1,5 +1,5 @@
salt.states.infoblox_a module
===========================
salt.states.infoblox_a
======================
.. automodule:: salt.states.infoblox_a
:members:

View file

@ -1,5 +1,5 @@
salt.states.infoblox_cname module
===========================
salt.states.infoblox_cname
==========================
.. automodule:: salt.states.infoblox_cname
:members:

View file

@ -1,5 +1,5 @@
salt.states.infoblox_host_record module
===========================
salt.states.infoblox_host_record
================================
.. automodule:: salt.states.infoblox_host_record
:members:

View file

@ -1,5 +1,5 @@
salt.states.infoblox_range module
===========================
salt.states.infoblox_range
==========================
.. automodule:: salt.states.infoblox_range
:members:

View file

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

View file

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

View file

@ -24,7 +24,7 @@ the targeting state. The following example demonstrates a direct requisite:
.. code-block:: yaml
vim:
pkg.installed: []
pkg.installed
/etc/vimrc:
file.managed:
@ -86,7 +86,7 @@ State target matching
~~~~~~~~~~~~~~~~~~~~~
In order to understand how state targets are matched, it is helpful to know
:ref:`how the state compiler is working <compiler_ordering>`. Consider the following
:ref:`how the state compiler is working <compiler-ordering>`. Consider the following
example:
.. code-block:: yaml
@ -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

View file

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

View file

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

View file

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

View file

@ -200,7 +200,7 @@ preferred:
``/srv/salt/apache/conf.sls``:
.. code-block:: yaml
.. code-block:: jinja
{% set name = 'httpd' %}
{% set tmpl = 'salt://apache/files/httpd.conf' %}
@ -234,7 +234,7 @@ locations within a single state:
``/srv/salt/apache/conf.sls``:
.. code-block:: yaml
.. code-block:: jinja
{% from "apache/map.jinja" import apache with context %}
@ -267,7 +267,8 @@ is not very modular to one that is:
.. code-block:: yaml
httpd:
pkg.installed: []
pkg:
- installed
service.running:
- enable: True
@ -331,7 +332,7 @@ modification of static values:
``/srv/salt/apache/map.jinja``:
.. code-block:: yaml
.. code-block:: jinja
{% set apache = salt['grains.filter_by']({
'Debian': {
@ -357,7 +358,7 @@ modification of static values:
``/srv/salt/apache/init.sls``:
.. code-block:: yaml
.. code-block:: jinja
{% from "apache/map.jinja" import apache with context %}
@ -387,7 +388,7 @@ to be broken into two states.
``/srv/salt/apache/map.jinja``:
.. code-block:: yaml
.. code-block:: jinja
{% set apache = salt['grains.filter_by']({
'Debian': {
@ -414,7 +415,7 @@ to be broken into two states.
``/srv/salt/apache/init.sls``:
.. code-block:: yaml
.. code-block:: jinja
{% from "apache/map.jinja" import apache with context %}
@ -427,7 +428,7 @@ to be broken into two states.
``/srv/salt/apache/conf.sls``:
.. code-block:: yaml
.. code-block:: jinja
{% from "apache/map.jinja" import apache with context %}
@ -521,7 +522,7 @@ the associated pillar:
``/srv/salt/mysql/testerdb.sls``:
.. code-block:: yaml
.. code-block:: jinja
testdb:
mysql_database.present:
@ -529,7 +530,7 @@ the associated pillar:
``/srv/salt/mysql/user.sls``:
.. code-block:: yaml
.. code-block:: jinja
include:
- mysql.testerdb

View file

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

View file

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

View file

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

View file

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

View file

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

View file

@ -149,10 +149,10 @@ with their default settings listed.
# The name of the image, from ``salt-cloud --list-images proxmox``
image: local:vztmpl/ubuntu-12.04-standard_12.04-1_amd64.tar.gz
# Whether or not to verify the SSL cert on the Proxmox host
verify_ssl: False
# Network interfaces, netX
net0: name=eth0,bridge=vmbr0,ip=dhcp
@ -172,7 +172,7 @@ QEMU profile file (for a new VM):
# Technology used to create the VM ('qemu', 'openvz'(on Proxmox <4.x) or 'lxc'(on Proxmox 4.x+))
technology: qemu
# Proxmox node name
host: node_name
@ -187,7 +187,7 @@ QEMU profile file (for a new VM):
# OS Type enum (other / wxp / w2k / w2k3 / w2k8 / wvista / win7 / win8 / l24 / l26 / solaris)
ostype: win7
# Hard disk location
sata0: <location>:<size>, format=<qcow2/vmdk/raw>, size=<size>GB #Example: local:120,format=qcow2,size=120GB
@ -231,7 +231,7 @@ QEMU profile file (for a clone):
# Technology used to create the VM ('qemu' or 'lxc')
technology: qemu
# Proxmox node name
host: node_name
@ -244,5 +244,11 @@ QEMU profile file (for a clone):
More information can be found on Proxmox API under the 'POST' method of /nodes/{node}/qemu/{vmid}/clone
.. note::
The Proxmox API offers a lot more options and parameters, which are not yet supported by this salt-cloud 'overlay'. Feel free to add your contribution by forking the github repository and modifying the following file: salt/salt/cloud/clouds/proxmox.py
An easy way to support more parameters for VM creation would be to add the names of the optional parameters in the 'create_nodes(vm_)' function, under the 'qemu' technology. But it requires you to dig into the code ...
The Proxmox API offers a lot more options and parameters, which are not yet
supported by this salt-cloud 'overlay'. Feel free to add your contribution
by forking the github repository and modifying the following file:
``salt/cloud/clouds/proxmox.py``
An easy way to support more parameters for VM creation would be to add the
names of the optional parameters in the 'create_nodes(vm\_)' function, under
the 'qemu' technology. But it requires you to dig into the code ...

View file

@ -149,7 +149,7 @@ This has also been tested to work with pipes, if needed:
.. code-block:: yaml
script_args: | head
script_args: '| head'
Remove Old SSH Keys
===================

View file

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

View file

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

View file

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

View file

@ -7,6 +7,7 @@ secure and troubleshoot, and how to perform many other administrative tasks.
.. toctree::
:maxdepth: 1
:glob:
../../ref/configuration/master
../../ref/configuration/minion
@ -18,6 +19,7 @@ secure and troubleshoot, and how to perform many other administrative tasks.
../jobs/job_cache
../jobs/external_cache
../../ref/configuration/logging/index
../../ref/configuration/logging/handlers/*
../../ref/file_server/index
../tutorials/gitfs
../tutorials/minionfs

View file

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

View file

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

View file

@ -12,38 +12,38 @@ You can use Salt Extend to quickly create templated modules for adding new behav
Salt Extend takes a template directory and merges it into a SaltStack source code directory.
Command line usage
~~~~~~~~~~~~~~~~~~
------------------
*See* :ref:`salt-extend <salt-extend>`
Choosing a template
~~~~~~~~~~~~~~~~~~~
-------------------
The following templates are available:
module
^^^^^^
******
Creates a new execution module within salt/modules/{{module_name}}.py
module_unit
^^^^^^^^^^^
***********
Creates a new execution module unit test suite within tests/unit/modules/test_{{module_name}}.py
state
^^^^^
*****
Creates a new state module within salt/states/{{module_name}}.py
state_unit
^^^^^^^^^^
**********
Creates a new state module unit test suite within tests/unit/states/test_{{module_name}}.py
Adding templates
~~~~~~~~~~~~~~~~
----------------
1. Create a directory under <src>/templates
2. Create a file ``template.yml`` containing properties for
@ -51,12 +51,12 @@ Adding templates
* ``description`` - a description of the template
* ``questions`` - a collection of additional questions to ask the user, the name of the item will
be used as the key in the context dictionary within the jinja template.
* ``question`` - The question to ask the user, as a string
* ``default`` - (optional) the default value, can contain Jinja2 template syntax and has access to the default context properties
Example template.yml
^^^^^^^^^^^^^^^^^^^^
********************
.. code-block:: yaml
@ -71,19 +71,19 @@ Example template.yml
3. Create the files within <src>/templates/<your template> to match the target
.. note::
File names can contain Jinja 2 template syntax, e.g. *'{{module_name}}.py}}'*
Example file in the template directory
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**************************************
.. code-block:: python
print('Hello {{module_name}}')
__virtual__ = '{{__virtual_name__}}'
Default context properties
^^^^^^^^^^^^^^^^^^^^^^^^^^
**************************
The default context provides the following properties
@ -97,10 +97,10 @@ The default context provides the following properties
As well as any additional properties entered from the questions section of ``template.yml``
API
~~~
---
salt.utils.extend module
========================
************************
.. automodule:: salt.utils.extend
:members:

View file

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

View file

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

View file

@ -34,7 +34,7 @@ Clone
In your CLI, navigate to the directory into which you want clone the Salt
codebase and submit the following command:
.. code-block:: shell
.. code-block:: bash
$ git clone https://github.com/<my_account>/salt.git
@ -42,7 +42,7 @@ where ``<my_account>`` is the name of your GitHub account. After the clone has
completed, add SaltStack as a second remote and fetch any changes from
``upstream``.
.. code-block:: shell
.. code-block:: bash
$ cd salt
$ git remote add upstream https://github.com/saltstack/salt.git
@ -53,7 +53,7 @@ the default branch for the SaltStack GitHub project. This branch needs to
track ``upstream/develop`` so that we will get all upstream changes when they
happen.
.. code-block:: shell
.. code-block:: bash
$ git checkout develop
$ git branch --set-upstream-to upstream/develop
@ -65,7 +65,7 @@ Fetch
Fetch any ``upstream`` changes on the ``develop`` branch and sync them to your
local copy of the branch with a single command:
.. code-block:: shell
.. code-block:: bash
$ git pull --rebase
@ -87,7 +87,7 @@ updated. I'll select the ``alternatives`` module.
Create a new branch off from ``develop``. Be sure to name it something short
and descriptive.
.. code-block:: shell
.. code-block:: bash
$ git checkout -b virt_ret
@ -97,10 +97,13 @@ Edit
Edit the file you have selected, and verify that the changes are correct.
.. code-block:: shell
.. code-block:: bash
$ vim salt/modules/alternatives.py
$ git diff
.. code-block:: diff
diff --git a/salt/modules/alternatives.py b/salt/modules/alternatives.py
index 1653e5f..30c0a59 100644
--- a/salt/modules/alternatives.py
@ -122,7 +125,7 @@ Commit
Stage and commit the changes. Write a descriptive commit summary, but try to
keep it less than 50 characters. Review your commit.
.. code-block:: shell
.. code-block:: bash
$ git add salt/modules/alternatives.py
$ git commit -m 'modules.alternatives: __virtual__ return err msg'
@ -143,7 +146,7 @@ Push
Push your branch to your GitHub account. You will likely need to enter your
GitHub username and password.
.. code-block:: shell
.. code-block:: bash
$ git push origin virt_ret
Username for 'https://github.com': <my_account>
@ -156,7 +159,7 @@ GitHub username and password.
you have done this, you may need add the keys to your git repository
configuration
.. code-block:: shell
.. code-block:: bash
$ git config ssh.key ~/.ssh/<key_name>

View file

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

View file

@ -119,9 +119,9 @@ can use the `Freenode webchat client`_ right from your browser.
`Logs of the IRC channel activity`_ are being collected courtesy of Moritz Lenz.
.. _Freenode:: http://freenode.net/irc_servers.shtml
.. _Freenode webchat client:: http://webchat.freenode.net/?channels=salt&uio=Mj10cnVlJjk9dHJ1ZSYxMD10cnVl83
.. _Logs of the IRC channel activity:: http://irclog.perlgeek.de/salt/
.. _Freenode: http://freenode.net/irc_servers.shtml
.. _`Freenode webchat client`: http://webchat.freenode.net/?channels=salt&uio=Mj10cnVlJjk9dHJ1ZSYxMD10cnVl83
.. _`Logs of the IRC channel activity`: http://irclog.perlgeek.de/salt/
If you wish to discuss the development of Salt itself join us in
``#salt-devel``.

View file

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

View file

@ -142,7 +142,7 @@ Optional Dependencies
settings)
* gcc - dynamic `Cython`_ module compiling
.. _`Python 2.6`: http://python.org/download/
.. _`Python 2.7`: http://python.org/download/
.. _`ZeroMQ`: http://zeromq.org/
.. _`pyzmq`: https://github.com/zeromq/pyzmq
.. _`msgpack-python`: https://pypi.python.org/pypi/msgpack-python/

View file

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

View file

@ -4,14 +4,13 @@
Understanding Jinja
===================
`Jinja <http://jinja.pocoo.org/docs/>`_ is the default templating language
in SLS files.
`Jinja`_ is the default templating language in SLS files.
.. _Jinja: http://jinja.pocoo.org/docs/templates/
Jinja in States
===============
.. _Jinja: http://jinja.pocoo.org/docs/templates/
Jinja is evaluated before YAML, which means it is evaluated before the States
are run.
@ -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') -%}

View file

@ -38,8 +38,8 @@ simply by creating a data structure. (And this is exactly how much of Salt's
own internals work!)
.. autoclass:: salt.netapi.NetapiClient
:members: local, local_async, local_subset, ssh, ssh_async,
runner, runner_async, wheel, wheel_async
:members: local, local_async, local_subset, ssh, runner, runner_async,
wheel, wheel_async
.. toctree::

View file

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

View file

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

View file

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

View file

@ -54,7 +54,7 @@ connection with the remote device only when required.
New in 2016.11.0
----------------
Proxy minions now support configuration files with names ending in '*.conf'
Proxy minions now support configuration files with names ending in '\*.conf'
and placed in /etc/salt/proxy.d.
Proxy minions can now be configured in /etc/salt/proxy or /etc/salt/proxy.d
@ -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.

View file

@ -47,8 +47,6 @@ You can find the source code for Salt on my GitHub page, I have also set up a
few wiki pages explaining how to use and set up Salt. If you are using Arch
Linux there is a package available in the Arch Linux AUR.
Salt 0.6.0 Source: :download:`salt-0.6.0.tar.gz`
GitHub page: |saltrepo|
Wiki: https://github.com/saltstack/salt/wiki

View file

@ -50,12 +50,8 @@ to Matthias Teege for tracking down some configuration bugs!
Salt can be downloaded from the following locations;
Source Tarball:
:download:`salt-0.7.0.tar.gz`
Arch Linux Package:
https://aur.archlinux.org/packages/salt-git/
Please enjoy the latest Salt release!
Please enjoy the latest Salt release!

View file

@ -5,8 +5,6 @@ Salt 0.8.0 release notes
Salt 0.8.0 is ready for general consumption!
The source tarball is available on GitHub for download:
:download:`salt-0.8.0.tar.gz`
A lot of work has gone into salt since the last release just 2 weeks ago, and
salt has improved a great deal. A swath of new features are here along with
performance and threading improvements!

View file

@ -13,7 +13,6 @@ but the back end to support expansion is in place.
I also recently gave a presentation to the Utah Python users group in Salt Lake
City, the slides from this presentation are available here:
:download:`Salt.pdf`
The video from this presentation will be available shortly.
@ -74,7 +73,5 @@ making debugging of minion modules MUCH easier.
Salt is nearing the goal of 1.0, where the core feature set and capability is
complete!
Salt 0.8.7 can be downloaded from GitHub here:
:download:`salt-0.8.7.tar.gz`
-Thomas S Hatch
-Thomas S Hatch

View file

@ -3,8 +3,7 @@ Salt 0.8.8 release notes
========================
Salt 0.8.8 is here! This release adds a great deal of code and some serious new
features. The latest release can be downloaded here:
:download:`salt-0.8.8.tar.gz`
features.
Improved Documentation has been set up for salt using sphinx thanks to the
efforts of Seth House. This new documentation system will act as the back end
@ -73,6 +72,5 @@ maintaining supreme usability and simplicity.
If you would like a more complete overview of Salt please watch the Salt
presentation:
Slides:
:download:`Salt.pdf`
-Thomas S Hatch
-Thomas S Hatch

View file

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

View file

@ -14,11 +14,7 @@ improvements to the ZeroMQ systems.
Download!
---------
The Salt source can be downloaded from the salt GitHub site:
:download:`salt-0.9.0.tar.gz`
Or from PyPI:
The Salt source can be downloaded from PyPI:
https://pypi.python.org/packages/source/s/salt/salt-0.9.0.tar.gz
@ -124,4 +120,4 @@ Extensive utilities for managing processes
publish
~~~~~~~
Used by the peer interface to allow minions to make publications
Used by the peer interface to allow minions to make publications

View file

@ -17,11 +17,7 @@ helping us clean up the states interface and make it ready for the world!
Download!
---------
The Salt source can be downloaded from the salt GitHub site:
:download:`salt-0.9.2.tar.gz`
Or from PyPI:
The Salt source can be downloaded from PyPI:
https://pypi.python.org/packages/source/s/salt/salt-0.9.2.tar.gz
@ -77,4 +73,4 @@ Cython Loading Disabled by Default
Cython loading requires a development tool chain to be installed on the minion,
requiring this by default can cause problems for most Salt deployments. If
Cython auto loading is desired it will need to be turned on in the minion
config.
config.

View file

@ -16,11 +16,7 @@ system has been greatly refined and many new features are available.
Download!
---------
The Salt source can be downloaded from the salt GitHub site:
:download:`salt-0.9.3.tar.gz`
Or from PyPI:
The Salt source can be downloaded from PyPI:
https://pypi.python.org/packages/source/s/salt/salt-0.9.3.tar.gz

View file

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

View file

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

View file

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

View file

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

View file

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

View 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

View file

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

View file

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

View file

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