mirror of
https://github.com/valitydev/salt.git
synced 2024-11-07 17:09:03 +00:00
f9ffcb697a
* json encode arguments passed to an execution module function call this fixes problems where you could pass a string to a module function, which thanks to the yaml decoder which is used when parsing command line arguments could change its type entirely. for example: __salt__['test.echo')('{foo: bar}') the test.echo function just returns the argument it's given. however, because it's being called through a salt-call process like this: salt-call --local test.echo {foo: bar} salt thinks it's yaml and therefore yaml decodes it. the return value from the test.echo call above is therefore a dict, not a string. * Prevent crash if pygit2 package is requesting re-compilation of the e… (#32652) * Prevent crash if pygit2 package is requesting re-compilation of the entire library on production systems (no *devel packages) * Fix PEP8: move imports to the top of the file * Move logger up * Add log error message in case if exception is not an ImportError * align OS grains from older SLES with current one (#32649) * Fixing critical bug to remove only the specified Host instead of the entire Host cluster (#32640) * yumpkg: Ignore epoch in version comparison for explict versions without an epoch (#32563) * yumpkg: Ignore epoch in version comparison for explict versions without an epoch Also properly handle comparisions for packages with multiple versions. Resolves #32229 * Don't attempt downgrade for kernel and its subpackages Multiple versions are supported since their paths do not conflict. * Lower log level for pillar cache (#32655) This shouldn't show up on salt-call runs * Don't access deprecated Exception.message attribute. (#32556) * Don't access deprecated Exception.message attribute. To avoid a deprecation warning message in logs. There is a new function salt.exceptions.get_error_message(e) instead. * Fixed module docs test. * Fix for issue 32523 (#32672) * Fix routes for redhat < 6 * Handle a couple of arguments better (Azure) (#32683) * backporting a fix from develop where the use of splay would result in seconds=0 in the schedule.list when there was no seconds specified in the origina schedule * Handle when beacon not configured and we try to enable/disable them (#32692) * Handle the situation when the beacon is not configured and we try to disable it * a couple more missing returns in the enable & disable * Check dependencies type before appling str operations (#32693) * Update external auth documentation to list supported matcher. (#32733) Thanks to #31598, all matchers are supported for eauth configuration. But we still have no way to use compound matchers in eauth configuration. Update the documentation to explicitly express this limitation. * modules.win_dacl: consistent case of dacl constants (#32720) * Document pillar cache options (#32643) * Add note about Pillar data cache requirement for Pillar targeting method * Add `saltutil.refresh_pillar` function to the scheduled Minion jobs * Minor fixes in docs * Add note about relations between `pillar_cache` option and Pillar Targeting to Master config comments with small reformatting * Document Pillar Cache Options for Salt Master * Document Minions Targeting with Mine * Remove `saltutil.refresh_pillar` scheduled persistent job * Properly handle minion failback failure. (#32749) * Properly handle minion failback failure. Initiate minion restart if all masters down on __master_disconnect like minion does on the initial master connect on start. * Fixed unit test * Improve documentation on pygit2 versions (#32779) This adds an explanation of the python-cffi dep added in pygit2 0.21.0, and recommends 0.20.3 for LTS distros. It also links to the salt-pack issue which tracks the progress of adding pygit2 to our Debian and Ubuntu repositories. * Pylint fix
182 lines
5.2 KiB
ReStructuredText
182 lines
5.2 KiB
ReStructuredText
.. _salt-mine:
|
|
|
|
.. index:: ! Mine, Salt Mine
|
|
|
|
=============
|
|
The Salt Mine
|
|
=============
|
|
|
|
The Salt Mine is used to collect arbitrary data from Minions and store it on
|
|
the Master. This data is then made available to all Minions via the
|
|
:py:mod:`salt.modules.mine` module.
|
|
|
|
Mine data is gathered on the Minion and sent back to the Master where only the
|
|
most recent data is maintained (if long term data is required use returners or
|
|
the external job cache).
|
|
|
|
Mine vs Grains
|
|
==============
|
|
|
|
Mine data is designed to be much more up-to-date than grain data. Grains are
|
|
refreshed on a very limited basis and are largely static data. Mines are
|
|
designed to replace slow peer publishing calls when Minions need data from
|
|
other Minions. Rather than having a Minion reach out to all the other Minions
|
|
for a piece of data, the Salt Mine, running on the Master, can collect it from
|
|
all the Minions every :ref:`mine-interval`, resulting in
|
|
almost fresh data at any given time, with much less overhead.
|
|
|
|
Mine Functions
|
|
==============
|
|
|
|
To enable the Salt Mine the ``mine_functions`` option needs to be applied to a
|
|
Minion. This option can be applied via the Minion's configuration file, or the
|
|
Minion's Pillar. The ``mine_functions`` option dictates what functions are
|
|
being executed and allows for arguments to be passed in. If no arguments are
|
|
passed, an empty list must be added:
|
|
|
|
.. code-block:: yaml
|
|
|
|
mine_functions:
|
|
test.ping: []
|
|
network.ip_addrs:
|
|
interface: eth0
|
|
cidr: '10.0.0.0/8'
|
|
|
|
Mine Functions Aliases
|
|
----------------------
|
|
|
|
Function aliases can be used to provide friendly names, usage intentions or to
|
|
allow multiple calls of the same function with different arguments. There is a
|
|
different syntax for passing positional and key-value arguments. Mixing
|
|
positional and key-value arguments is not supported.
|
|
|
|
.. versionadded:: 2014.7.0
|
|
|
|
.. code-block:: yaml
|
|
|
|
mine_functions:
|
|
network.ip_addrs: [eth0]
|
|
networkplus.internal_ip_addrs: []
|
|
internal_ip_addrs:
|
|
mine_function: network.ip_addrs
|
|
cidr: 192.168.0.0/16
|
|
ip_list:
|
|
- mine_function: grains.get
|
|
- ip_interfaces
|
|
|
|
|
|
.. _mine_interval:
|
|
|
|
Mine Interval
|
|
=============
|
|
|
|
The Salt Mine functions are executed when the Minion starts and at a given
|
|
interval by the scheduler. The default interval is every 60 minutes and can
|
|
be adjusted for the Minion via the ``mine_interval`` option:
|
|
|
|
.. code-block:: yaml
|
|
|
|
mine_interval: 60
|
|
|
|
Mine in Salt-SSH
|
|
================
|
|
|
|
As of the 2015.5.0 release of salt, salt-ssh supports ``mine.get``.
|
|
|
|
Because the Minions cannot provide their own ``mine_functions`` configuration,
|
|
we retrieve the args for specified mine functions in one of three places,
|
|
searched in the following order:
|
|
|
|
1. Roster data
|
|
2. Pillar
|
|
3. Master config
|
|
|
|
The ``mine_functions`` are formatted exactly the same as in normal salt, just
|
|
stored in a different location. Here is an example of a flat roster containing
|
|
``mine_functions``:
|
|
|
|
.. code-block:: yaml
|
|
|
|
test:
|
|
host: 104.237.131.248
|
|
user: root
|
|
mine_functions:
|
|
cmd.run: ['echo "hello!"']
|
|
network.ip_addrs:
|
|
interface: eth0
|
|
|
|
.. note::
|
|
|
|
Because of the differences in the architecture of salt-ssh, ``mine.get``
|
|
calls are somewhat inefficient. Salt must make a new salt-ssh call to each
|
|
of the Minions in question to retrieve the requested data, much like a
|
|
publish call. However, unlike publish, it must run the requested function
|
|
as a wrapper function, so we can retrieve the function args from the pillar
|
|
of the Minion in question. This results in a non-trivial delay in
|
|
retrieving the requested data.
|
|
|
|
Minions Targeting with Mine
|
|
===========================
|
|
|
|
The ``mine.get`` function supports various methods of :ref:`Minions targeting
|
|
<targeting>` to fetch Mine data from particular hosts, such as glob or regular
|
|
expression matching on Minion id (name), grains, pillars and :ref:`compound
|
|
matches <targeting-compound>`. See the :py:mod:`salt.modules.mine` module
|
|
documentation for the reference.
|
|
|
|
.. note::
|
|
|
|
Pillar data needs to be cached on Master for pillar targeting to work with
|
|
Mine. Read the note in :ref:`relevant section <targeting-pillar>`.
|
|
|
|
Example
|
|
=======
|
|
|
|
One way to use data from Salt Mine is in a State. The values can be retrieved
|
|
via Jinja and used in the SLS file. The following example is a partial HAProxy
|
|
configuration file and pulls IP addresses from all Minions with the "web" grain
|
|
to add them to the pool of load balanced servers.
|
|
|
|
:file:`/srv/pillar/top.sls`:
|
|
|
|
.. code-block:: yaml
|
|
|
|
base:
|
|
'G@roles:web':
|
|
- web
|
|
|
|
:file:`/srv/pillar/web.sls`:
|
|
|
|
.. code-block:: yaml
|
|
|
|
mine_functions:
|
|
network.ip_addrs: [eth0]
|
|
|
|
:file:`/etc/salt/minion.d/mine.conf`:
|
|
|
|
.. code-block:: yaml
|
|
|
|
mine_interval: 5
|
|
|
|
:file:`/srv/salt/haproxy.sls`:
|
|
|
|
.. code-block:: yaml
|
|
|
|
haproxy_config:
|
|
file.managed:
|
|
- name: /etc/haproxy/config
|
|
- source: salt://haproxy_config
|
|
- template: jinja
|
|
|
|
:file:`/srv/salt/haproxy_config`:
|
|
|
|
.. code-block:: yaml
|
|
|
|
<...file contents snipped...>
|
|
|
|
{% for server, addrs in salt['mine.get']('roles:web', 'network.ip_addrs', expr_form='grain') | dictsort() %}
|
|
server {{ server }} {{ addrs[0] }}:80 check
|
|
{% endfor %}
|
|
|
|
<...file contents snipped...>
|