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: external auth.
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 file server.
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: state layers.
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
are not idempotent by default but can be made idempotent with the
proper use of requisites such as unless
and onlyif. For more information, see
A templating language which allows variables and simple logic to be
dynamically inserted into static text files when they are rendered.
Salt's Jinja documentation.
The complete set of tasks to be performed by the execution of a Salt
command are a single job. See also:
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 minions.
A minion which does not require a Salt master to operate. All
configuration is local. See also:
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: peer communication.
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.
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: composing renderers.
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 module containing a set of runner functions. See also: list of runner modules.
A function which is called by the salt-run command and executes on the master instead of on a minion. See also: Runner Module.
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 controlled.
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:
Used to manage the creation and deployment of virtual machines onto a
set of host machines. Often used to create and deploy private clouds.
Contains a set of state declarations.
Translates highdata into lowdata.
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 module which contains a set of state functions. See also: list of state modules.
The application of a set of states on a set of systems.
A forwarder which can relay messages between tiered masters. See also: Syndic.
Minion(s) to which a given salt command will apply. See also: targeting.
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: