Support relative includes for pillar

[pniederw]

The dot notation that's supported for relative includes in state files (include: - .other) doesn't seem to work for pillar. Would be just as useful there.

[basepi]

Sounds reasonable to me. Thanks for the request!

[arnisoph]

+1

[craig5]

+1

[pykler]

+1

[eliasp]

It seems to be broken in general. See also #14497.
I wonder whether the breakage of relative includes in pillars is caused by the same bug.

[basepi]

Very possible, thanks for tagging these together @eliasp.

[wuxxin]

+1
because this way you can write pillar state files that are identical, and just edit common.sls (in the same subdir), to change some values

---

something/common.sls
{% load_yaml as common %}
test:
   whatever: true
   another:
      hu: he
{% endload %}

---

something/another.sls

include:
  - .common

{{ common.something }}

[uvsmtid]

To complement this issue, this is how to live now with workaround which I personally use extensively.

Workaround

Push a variable with location of the pillar into the pillar template being included using defaults as described in doc how to include pillar.

Example

The top file is not used, but it's important to note that it cannot use include directly.

All we need to do is to list the first "entry point" pillar which will include others.

# top.sls
base:
    '*':
        - main

Include pillar and tell it where it is located using this_pillar.

# main.sls
include:
    - deep.inside.directory.structure.pillar_a:
        defaults:
            this_pillar: deep.inside.directory.structure.pillar_a

Include other pillars relatively:

# deep.inside.directory.structure.pillar_a.sls
include:
    - {{ this_pillar }}.whatever:
    - {{ this_pillar }}.blah_blah_blah:
    - {{ this_pillar }}.last_one:

Proper complication

Because you don't know (or you don't want to keep this in mind) whether any pillar subsequently includes relatively anything else or not, the safest way is to pass this_pillar recursively to every other one being included (just in case).

# deep.inside.directory.structure.pillar_a.sls
include:
    - {{ this_pillar }}.whatever:
        defaults:
            this_pillar: {{ this_pillar }}.whatever
    - {{ this_pillar }}.blah_blah_blah:
        defaults:
            this_pillar: {{ this_pillar }}.blah_blah_blah
    - {{ this_pillar }}.last_one:
        defaults:
            this_pillar: {{ this_pillar }}.last_one

or wrapped in a loop:

# deep.inside.directory.structure.pillar_a.sls
include:
    {% for sub_item in [ 'whatever', 'blah_blah_blah', 'last_one ] %}
    - {{ this_pillar }}.{{ sub_item }}:
        defaults:
            this_pillar: {{ this_pillar }}.{{ sub_item }}
    {% endfor%}

Conclusion

It's ugly, but it works.

[titilambert]

+1

[enver]

+1

[adithep]

+1

[peter-slovak]

+1

[damon-atkins]

+1

[mlalpho]

+1

[damon-atkins]

+1

[damon-atkins]

@meggiebot please add Labels Core & Pillar if appropriate.

[ealphonse]

Hi, it is also the case when one - require: - sls: a sls in a salt file.

[mallniya]

+1
shockingly sudden it's not implemented yet

[nomoo]

+1

[SuperTux88]

There is a 👍 functionality in GitHub nowadays ... there is no need to +1 anymore, because it only create unneeded notifications, thanks.

[danlsgiga]

Just hit this very same issue too. Will change my formulas to use the absolute path instead of relative.
Would be helpful if the Pillar docs had a note letting people know that pillar requires absolute paths for template imports.

[damon-atkins]

@Ch3LL can this request be escalated into the up coming release its such a large difference between states and pillars.

[Ch3LL]

ping @saltstack/team-core anyone have interest in tackling this one?

[damon-atkins]

The following is support in states however not supported in pillar

include:
  - .common

Lets keep this on the radar if you want this in pillars, please thumbs up the original comment/description
Issues Sorted by Top Thumbs Up

[clallen]

+1