Documentation inconsistency?

[johnnybubonic]

Description of Issue/Question

(sorry for so many pillar-related issues; I'm obviously working through some stuff. heh)

In Storing Static Data in the Pillar, the Declaring the Master Pillar section states:

Salt pillars can use the same matcher types as the standard top file.

Per that linked page's Advanced Minion Targeting section,

The available match types which can be set for a target expression in the top file are:
(...)
pillar | Pillar match, optionally using globbing (e.g. role:webserver or role:web*)
(...)

And this comment seems to confirm that one should be able to match external pillars (ext_pillars, in my case) in a pillar top file.

However, this does not seem to be the case (at least in 2018.3.3), as e.g.

<pillar_root>/top.sls:

base:
  'my_ext_pillar:key:value':
    - match: pillar
    - <pillar_subdir_with_init.sls>

does not seem to work.

Running a state.apply (highstate):

<minion>:
    Data failed to compile:
----------
    Pillar failed to render with the following messages:
----------
    Rendering Primary Top file failed, render error:
Jinja variable 'dict object' has no attribute 'pillar'

Running a pillar.items succeeds and renders everything properly, though. So I don't know what's going on, here.

If this functionality was removed, the line in "Declaring the Master Pillar" may want to be changed to something like the following:

--- a	2019-01-30 01:01:59.162141449 -0500
+++ b	2019-01-30 01:05:06.771032788 -0500
@@ -1,2 +1,2 @@
-Salt pillars can use the same matcher types as the standard <a class="reference internal" href="../../ref/states/top.html#states-top"><span class="std std-ref">top
+Salt pillars can use the same matcher types (<em>except</em> <code><span class="pre">pillar</span></code>) as the standard <a class="reference internal" href="../../ref/states/top.html#states-top"><span class="std std-ref">top
 file</span></a>.</p>

[johnnybubonic]

Oh, gorram it.

Stopped the minion, deleted the cache, started it again. Works now.

So it looks like it was a bad cache, but I wanna leave this open for a day or two in case I hit it again and it's reproducible.

[dwoz]

@johnnybubonic Thanks for looking into this.

[johnnybubonic]

@dwoz 'course! i haven't hit into it again and i've run several highstates fleetwide in my vm lab (where it occurred) since with all returning success, so i'm thinking it was just a fluke. closing, as i can't reproduce (thankfully!).