The evaluation of states in the order that they are defined in a SLS
file. See also: ordering.
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.
A combination of many target definitions that can be combined with
boolean operators. See also: targeting.
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:
A directory tree containing state files which can be applied to
minions. See also: top file.
A Python function inside an Execution Module that may take arguments
and performs specific system-management tasks. See also: the
list of execution modules.
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: the
list of execution modules.
A module that accepts arbitrary arguments and returns a dictionary.
The dictionary is automatically added to a pillar for a minion.
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: Salt Reactor.
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: Salt's
A key-value pair which contains a fact about a system, such as its
hostname, network addresses. See also: targeting with grains.
The data structure in a SLS file the represents a set of state
declarations. See also: state layers.
The collection of states to be applied to a system. See also:
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 cmd.run
are not idempotent by default but can be made idempotent with the
proper use of requisites such as unless
and onlyif. For more information, seewikipedia.
A templating language which allows variables and simple logic to be
dynamically inserted into static text files when they are rendered.
See also: Salt'sJinjadocumentation.
The complete set of tasks to be performed by the execution of a Salt
command are a single job. See also: jobsrunner.
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.
A unique identifier to represent a given job. This is often
shortened to JID.
The collection of processed states after requisites and order are
evaluated. See also: state layers.
A central Salt daemon from which commands can be issued to listening
A minion which does not require a Salt master to operate. All
configuration is local. See also: file_client.
A system for the master that allows hooks into external systems to
generate top file data.
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: Salt Mine.
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.
A globally unique identifier for a minion. See also:
The ability for a minion to be actively connected to multiple Salt
masters at the same time in high-availability environments.
A pre-defined group of minions declared in the master configuration
file. See also: targeting.
A formatter for defining the characteristics of output data from a Salt
command. See also: list of outputters.
The ability for minions to communicate directly with other minions
instead of brokering commands through the Salt master. See also:
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: Pillar, list of Pillar
A minion which can control devices that are unable to run a Salt minion
locally, such as routers and switches.
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: PyDSL.
An interface for listening to events and defining actions that Salt
should taken upon receipt of given events. See also: Reactor.
Allows SLS files to be rendered by multiple renderers, with each
renderer receiving the output of the previous. See also:
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: list of renderers.
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:
list of returners.
A flat-file list of target hosts. (Currently only used by salt-ssh.)
A function which is called by the salt-run command and
executes on the master instead of on a minion. See also:
A suite of tools used to create and deploy systems on many hosted cloud
providers. See also: salt-cloud.
A configuration management and remote orchestration system that does
not require that any software besides SSH be installed on systems to be
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: thinrunner.
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: virtrunner.
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: highstate structure.
A function contained inside a state module which
can manages the application of a particular state to a system. State
functions frequently call out to one or more execution modules to perform a given task.
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.
A master process which can send notices and receive replies from
minions. See also:
Generated on March 23, 2019 at 07:01:57 MDT.
You are viewing docs for the latest stable release, 2019.2.0. Switch to docs for the previous stable release, 2018.3.4, or to a recent doc build from the develop branch.