Glossary¶

Auto-Order¶: The evaluation of states in the order that they are defined in a SLS file. See also: ordering.
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.
Compound Matcher¶: A combination of many target definitions that can be combined with boolean operators. See also: targeting.
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: external auth.
Environment¶: A directory tree containing state files which can be applied to minions. See also: top file.
Execution Function¶: A Python function inside an Execution Module that may take arguments and performs specific system-management tasks. See also: the list of execution modules.
External Job Cache¶: An external data-store that can archive information about jobs that have been run. A default returner. See also: ext_job_cache, the list of 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: the list of execution 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: Salt 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: Salt's file server.
Grain¶: A key-value pair which contains a fact about a system, such as its hostname, network addresses. See also: targeting with grains.
Highdata¶: The data structure in a SLS file the represents a set of state declarations. See also: state layers.
Highstate¶: The collection of states to be applied to a system. See also: state layers.
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 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, see wikipedia.
Jinja¶: A templating language which allows variables and simple logic to be dynamically inserted into static text files when they are rendered. See also: Salt's Jinja documentation.
Job¶: The complete set of tasks to be performed by the execution of a Salt command are a single job. See also: jobs runner.
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 job. This is often shortened to JID.
Low State¶: The collection of processed states after requisites and order are evaluated. See also: state layers.
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: 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: 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: 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: targeting.
Outputter¶: A formatter for defining the characteristics of output data from a Salt command. See also: list of outputters.
Peer Communication¶: The ability for minions to communicate directly with other minions instead of brokering commands through the Salt master. See also: peer communication.
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: Pillar, list of Pillar modules.
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: PyDSL.
Reactor¶: An interface for listening to events and defining actions that Salt should taken upon receipt of given events. See also: Reactor.
Render Pipe¶: Allows SLS files to be rendered by multiple renderers, with each renderer receiving the output of the previous. See also: composing renderers.
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: list of 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: list of 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: list of runner modules.
Runner Function¶: A function which is called by the salt-run command and executes on the master instead of on a minion. See also: Runner Module.
Salt Cloud¶: A suite of tools used to create and deploy systems on many hosted cloud providers. See also: 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: thin runner.
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: virt runner.
SLS Module¶: Contains a set of state declarations.
State Compiler¶: Translates 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: highstate structure.
State Function¶: 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.
State Module¶: A module which contains a set of state functions. See also: list of state modules.
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: Syndic.
Target¶: Minion(s) to which a given salt command will apply. See also: targeting.
Top File¶: Determines which SLS files should be applied to various systems and organizes those groups of systems into environments. See also: top file, list of master top modules.
__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: worker_threads.