.. glossary::
Auto-Order
The evaluation of states in the order that they are defined in a SLS
file. *See also*: :ref:`ordering <ordering_auto_order>`.
Bootstrap
A stand-alone Salt project which can download and install a Salt master
and/or a Salt minion onto a host. *See also*: `salt-bootstrap
<https://github.com/saltstack/salt-bootstrap>`_.
Compound Matcher
A combination of many target definitions that can be combined with
boolean operators. *See also*: :ref:`targeting <targeting-compound>`.
EAuth
Shorthand for 'external authentication'. A system for calling to a
system outside of Salt in order to authenticate users and determine if
they are allowed to issue particular commands to Salt. *See also*:
:ref:`external auth<acl-eauth>`.
Environment
A directory tree containing state files which can be applied to
minions. *See also*: :ref:`top file<states-top-environments>`.
Execution Function
A Python function inside an Execution Module that may take arguments
and performs specific system-management tasks. *See also*: :ref:`the
list of execution modules <all-salt.modules>`.
External Job Cache
An external data-store that can archive information about jobs that
have been run. A default returner. *See also*:
:conf_master:`ext_job_cache`, :ref:`the list of returners
<all-salt.returners>`.
Execution Module
A Python module that contains execution functions which directly
perform various system-management tasks on a server. Salt ships with a
number of execution modules but users can also write their own
execution modules to perform specialized tasks. *See also*: :ref:`the
list of execution modules <all-salt.modules>`.
External Pillar
A module that accepts arbitrary arguments and returns a dictionary.
The dictionary is automatically added to a pillar for a minion.
Event
A notice emitted onto an event bus. Events are often driven by requests
for actions to occur on a minion or master and the results of those
actions. *See also*: :ref:`Salt Reactor <reactor>`.
File Server
A local or remote location for storing both Salt-specific files such as
top files or SLS files as well as files that can be distributed to
minions, such as system configuration files. *See also*: :ref:`Salt's
file server <file-server>`.
Grain
A key-value pair which contains a fact about a system, such as its
hostname, network addresses. *See also*: :ref:`targeting with grains
<targeting-grains>`.
Highdata
The data structure in a SLS file the represents a set of state
declarations. *See also*: :ref:`state layers
<state-layers-high-data>`.
Highstate
The collection of states to be applied to a system. *See also*:
:ref:`state layers <state-layers-highstate>`.
Idempotent
An action that ensures the system is in a well-known state regardless
of the system's state before the action is applied. A corollary to
this is that applying the action multiple times results in no changes
to the system. State module functions should be idempotent. Some
state module functions, such as :mod:`cmd.run <salt.states.cmd.run>`
are not idempotent by default but can be made idempotent with the
proper use of requisites such as :ref:`unless <unless-requisite>`
and :ref:`onlyif <onlyif-requisite>`. For more information, *see*
`wikipedia <https://en.wikipedia.org/wiki/Idempotent>`_.
Jinja
A templating language which allows variables and simple logic to be
dynamically inserted into static text files when they are rendered.
*See also*: :py:mod:`Salt's Jinja documentation
<salt.renderers.jinja>`.
Job
The complete set of tasks to be performed by the execution of a Salt
command are a single job. *See also*: :py:mod:`jobs runner
<salt.runners.jobs>`.
Job Cache
A storage location for job results, which may then be queried by a
salt runner or an external system. May be local to a salt master
or stored externally.
Job ID
A unique identifier to represent a given :term:`job <Job>`. This is often
shortened to JID.
Low State
The collection of processed states after requisites and order are
evaluated. *See also*: :ref:`state layers <state-layers-low-state>`.
Master
A central Salt daemon from which commands can be issued to listening
minions.
Masterless
A minion which does not require a Salt master to operate. All
configuration is local. *See also*: :conf_minion:`file_client`.
Master Tops
A system for the master that allows hooks into external systems to
generate top file data.
Mine
A facility to collect arbitrary data from minions and store that data
on the master. This data is then available to all other minions.
(Sometimes referred to as Salt Mine.) *See also*: :ref:`Salt Mine
<salt-mine>`.
Minion
A server running a Salt minion daemon which can listen to commands from
a master and perform the requested tasks. Generally, minions are
servers which are to be controlled using Salt.
Minion ID
A globally unique identifier for a minion. *See also*:
:conf_minion:`id`.
Multi-Master
The ability for a minion to be actively connected to multiple Salt
masters at the same time in high-availability environments.
Node Group
A pre-defined group of minions declared in the master configuration
file. *See also*: :ref:`targeting <targeting-nodegroups>`.
Outputter
A formatter for defining the characteristics of output data from a Salt
command. *See also*: :ref:`list of outputters <all-salt.output>`.
Peer Communication
The ability for minions to communicate directly with other minions
instead of brokering commands through the Salt master. *See also*:
:ref:`peer communication <peer>`.
Pillar
A simple key-value store for user-defined data to be made available to
a minion. Often used to store and distribute sensitive data to minions.
*See also*: :ref:`Pillar <salt-pillars>`, :ref:`list of Pillar
modules <all-salt.pillars>`.
Proxy Minion
A minion which can control devices that are unable to run a Salt minion
locally, such as routers and switches.
PyDSL
A Pythonic domain-specific-language used as a Salt renderer. PyDSL can
be used in cases where adding pure Python into SLS files is beneficial.
*See also*: :py:mod:`PyDSL <salt.renderers.pydsl>`.
Reactor
An interface for listening to events and defining actions that Salt
should taken upon receipt of given events. *See also*: :ref:`Reactor
<reactor>`.
Render Pipe
Allows SLS files to be rendered by multiple renderers, with each
renderer receiving the output of the previous. *See also*:
:ref:`composing renderers <renderers-composing>`.
Renderer
Responsible for translating a given data serialization format such as
YAML or JSON into a Python data structure that can be consumed by Salt.
*See also*: :ref:`list of renderers <all-salt.renderers>`.
Returner
Allows for the results of a Salt command to be sent to a given
data-store such as a database or log file for archival. *See also*:
:ref:`list of returners <all-salt.returners>`.
Roster
A flat-file list of target hosts. (Currently only used by salt-ssh.)
Runner Module
A module containing a set of runner functions. *See also*: :ref:`list
of runner modules <all-salt.runners>`.
Runner Function
A function which is called by the :command:`salt-run` command and
executes on the master instead of on a minion. *See also*:
:term:`Runner Module`.
Salt Cloud
A suite of tools used to create and deploy systems on many hosted cloud
providers. *See also*: :ref:`salt-cloud <salt-cloud>`.
Salt SSH
A configuration management and remote orchestration system that does
not require that any software besides SSH be installed on systems to be
controlled.
Salt Thin
A subset of the normal Salt distribution that does not include any
transport routines. A Salt Thin bundle can be dropped onto a host and
used directly without any requirement that the host be connected to a
network. Used by Salt SSH. *See also*: :py:mod:`thin runner
<salt.runners.thin>`.
Salt Virt
Used to manage the creation and deployment of virtual machines onto a
set of host machines. Often used to create and deploy private clouds.
*See also*: :py:mod:`virt runner <salt.runners.virt>`.
SLS Module
Contains a set of :term:`state declarations <State Declaration>`.
State Compiler
Translates :term:`highdata <Highdata>` into lowdata.
State Declaration
A data structure which contains a unique ID and describes one or more
states of a system such as ensuring that a package is installed or a
user is defined. *See also*: :ref:`highstate structure
<state-declaration>`.
State Function
A function contained inside a :term:`state module <State Module>` which
can manages the application of a particular state to a system. State
functions frequently call out to one or more :term:`execution modules
<Execution Module>` to perform a given task.
State Module
A module which contains a set of state functions. *See also*:
:ref:`list of state modules <all-salt.states>`.
State Run
The application of a set of states on a set of systems.
Syndic
A forwarder which can relay messages between tiered masters. **See
also**: :ref:`Syndic <syndic>`.
Target
Minion(s) to which a given salt command will apply. *See also*:
:ref:`targeting <targeting>`.
Top File
Determines which SLS files should be applied to various systems and
organizes those groups of systems into environments. *See also*:
:ref:`top file <states-top>`, :ref:`list of master top modules
<all-salt.tops>`.
__virtual__
A function in a module that is called on module load to determine
whether or not the module should be available to a minion. This
function commonly contains logic to determine if all requirements
for a module are available, such as external libraries.
Worker
A master process which can send notices and receive replies from
minions. *See also*:
:conf_master:`worker_threads`.