Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Salt Grains vs Pillars

Salt Grains vs Pillars

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

Default use case

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/minion file (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).

Distributed vs Centralized

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.

Manual vs Automatic

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.

System-wide vs Node-specific

  • 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.

Good vs Bad

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.

[footer]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.