4.2 The Terminology Problem

Salt has some ‘odd’ terminology. This takes some getting used to but once mastered it becomes quite natural.

We will investigate each of these as we encounter them in the course, but for now just be aware of these terms.

master
A computer designated as a controller.
minion
A device to be controlled by SaltStack.
grain
Theses are data on each minion.
state
A definition of some desired setup for a minion.
state module
A piece of code that assures a particular state on a minion.
execution module
A piece of code that affects a change on a minion1.
pillar
Data hosted on the master.
mine
A subsystem allowing minions to selectively and securely share there grain data with the master (and subsequently other minions).
beacon
An agent to monitor a minion and report to the master.
reactor
A subsystem running on a master, reacting to events on the SaltStack event bus.
runner
Similar to execution module but runners operate on a master rather than a minion.
orchestration runner
A specialised runner for coordinating the configuration of several minions.

As you can see the SaltStack development team leaned into the ‘salt’ metaphor quite heavily.

Another problem is that there is a lot of ambiguity in the use of some terms. Particularly, ‘state’ is sometimes used to refer to a state file and at other times to refer to blocks within a state file. To avoid this particular issue I use ‘state’ to refer to the file and ‘state stanza’ to refer to blocks within a state file. When other ambiguities arise I will introduce consistent terms and refer to the appendices to discuss the relevant issue.

1The difference between state module code and execution module code is often confusing to new users. Briefly, a state module checks that some condition is true on a minion, if the condition is not met the state module code calls one of more execution modules to affect change on the minion so that the condition is met. We look at this process in detail fairly early in the course.