Both grains and Pillars define input data to parameterize Salt states.
Depending on the purpose of data, one should make a choice to put it in one place or another.
NOTE:
- This doc focuses on practical differences between Grains and Pillars for default use case only.
- It is not about everything what is possible.
| Differences | Grains | Pillars |
|---|---|---|
| Info which... | ... Minion knows about itself | ... Minion asks Master about |
| Distributed: | Yes | No |
| Centralized: | No | Yes |
| Computed automatically: | Yes (mostly should) | No |
| Assigned manually: | No (or kept to minimum) | Yes |
| Conceptually intrinsic to... | ... individual Minion node | ... entire system managed by Master |
| Data under revision control: | No (if static values) | Yes |
| Define rather... | provided resources | required resources |
In our default case entire system is managed by single person (authority).
By default Grains are both:
- good case: evaluated automatically by Minion software in built-in (like functions in
core.py) or custom Grains; - bad case: assigned manually in
/etc/salt/minionfile (or files it includes) on each Minion individually.
By default Pillars are data defined manually in files under /srv/pillars.
If not sure, it is almost always good to define required data in pillar (first).
Because Grains are distributed, they are disadvantageous for manual management: one has to access Minions individually to configure Grains for specific Minion.
Instead, it is more convenient to define manual data centrally in Pillars.
It is crucial to differentiate between static and non-static custom Grains:
- Static grains have to be distributed across Minions (in their configuration files).
- Non-static grains are effectively centralized on Master and pushed to Minions for evaluation.
Probably, the only static Grain one wants to define is Minion id.
The rest information about Minion should either be assigned to it
through Pillars (using Minion id as a key)
or evaluated in non-static grains.
In other words:
- static Grains are the bad (impractical) use of Grains;
- non-static Grains are the good (practical) use of Grains.
This also suggests that:
- Pillars values are normally under revision control centrally on Master;
- static Grains values are less convenient to be kept revisioned (or even used);
- source code (not values) for non-static Grains is also normally under revision control on Master.
Because Grains can be computed automatically, they are meant to collect information which is Minion-specific and unknown in advance.
The only practical case for custom Grains are non-static ones with their is automatic evaluation on Minion.
Pillars are to be manually defined for required state of the system which Salt is supposed to manage and enforce.
- Pillars suit more to define (top-down) entire system of Minions as required: roles, credentials, platforms, policies, etc.
- Grains suit more to define (bottom-up) environment of individual Minions as provided.
Defining good as practical and bad as impractical is heavily influenced by managing system with two hands at a time (single person).
In other cases, static grains may actually be very useful to let (multiple) owners of individual hodes manage preferences. This effectively makes distributed nature of static Grains match nature of responsibilities distributed among the owners. This is simply not default use case.