Should I always use pillar.get instead of pillar['foo']?

Question

I see in the pillar documentation that there are two ways to reference pillar data in an SLS.

{{ pillar['foo'] }}

and

{{ salt['pillar.get']('foo') }}

The pillar.get method handles nested pillar data better and allows to specify a default if the data isn't found in the pillar. But it's a bit more typing and I find the first method easier to read.

So, is it considered best practice to always use the pillar.get method or is using the pillar['foo'] acceptable, especially when dealing with non-nested pillar data.

I suspect always using the pillar.get method is best since it make sense to use it when dealing with nested pillar data or you want to set a default. And it's best to just you one method consistently. But I wanted to get other people's thoughts.

Answer 1

I use pillar['foo'] for "required" options, as Utah_Dave suggests. I use salt['pillar.get']('foo', 'default') for options that have a sane default. There are a couple other variations that are interesting.

One is salt['defaults.get']('foo'), which allows you to keep your state's default values in a separate file. Very useful if you have a lot of possible pillar variables, most or all of which have default values. (NOTE: the behavior of defaults.get has changed since I wrote this, see this answer for other options)

A second is that it is possible to alias salt['pillar.get'] (and other functions of the same sort) so that they are less of a nuisance to type and read:

{%- set pget = salt['pillar.get'] %}
{%- set dget = salt['defaults.get'] %}
{%- set mget = salt['mine.get'] %}
{{ pget("foo1", "default1") }}
{{ pget("foo2", "default2") }}
{{ dget("foo3") }}
{{ dget("foo4") }}
...and so on.

That last variation in particular (dget) works wonders for readability in heavily-customizable states.