pillar.show_top runner doesn't work with git_pillar

[wt]

I get no output for the following command:

# salt-run pillar.show_top <host>
#

I would have expected to see the data generated from top.sls in my pillar git repo. I have no file pillars. I only have pillars from git. Here's the relevant part of my /etc/salt/master config:

ext_pillar:
  - git: master git+ssh://git@gitserver.example.com/sf-pillar.git

Here's my version info:

# salt-run --versions
           Salt: 2015.5.2
         Python: 2.6.9 (unknown, Apr  1 2015, 18:16:00)
         Jinja2: 2.7.2
       M2Crypto: 0.21.1
 msgpack-python: 0.4.6
   msgpack-pure: Not Installed
       pycrypto: 2.6.1
        libnacl: Not Installed
         PyYAML: 3.10
          ioflo: Not Installed
          PyZMQ: 14.3.1
           RAET: Not Installed
            ZMQ: 3.2.5
           Mako: Not Installed

I am using the version packages in EPEL6 on Amazon Linux.

[jfindlay]

@wt, thanks for the report.

[cachedout]

That's interesting. Do the minions log show any indication that it's trying to fetch the pillar top file?

[wt]

Does salt-run have anything to do with minions?

Here's another run with debug logs:

# salt-run -l debug pillar.show_top blah.example.com
[DEBUG   ] Reading configuration from /etc/salt/master
[DEBUG   ] Using cached minion ID from /etc/salt/minion_id: blah.example.com
[DEBUG   ] Configuration file path: /etc/salt/master
[DEBUG   ] LazyLoaded pillar.show_top
[DEBUG   ] MasterEvent PUB socket URI: ipc:///var/run/salt/master/master_event_pub.ipc
[DEBUG   ] MasterEvent PULL socket URI: ipc:///var/run/salt/master/master_event_pull.ipc
[DEBUG   ] Sending event - data = {'_stamp': '2015-08-07T20:30:05.898217'}
[DEBUG   ] Sending event - data = {'fun': 'runner.pillar.show_top', 'jid': '20150807203005897069', 'user': 'root', '_stamp': '2015-08-07T20:30:05.899329'}
[DEBUG   ] LazyLoaded jinja.render
[DEBUG   ] LazyLoaded yaml.render
[DEBUG   ] LazyLoaded nested.output
[DEBUG   ] Sending event - data = {'jid': '20150807203005897069', 'return': defaultdict(<class 'ordereddict.OrderedDict'>, {}), 'success': True, '_stamp': '2015-08-07T20:30:05.971678', 'user': 'root', 'fun': 'runner.pillar.show_top'}
[DEBUG   ] Reading configuration from /etc/salt/master
[DEBUG   ] Including configuration from '/etc/salt/minion.d/_schedule.conf'
[DEBUG   ] Reading configuration from /etc/salt/minion.d/_schedule.conf
[DEBUG   ] Using cached minion ID from /etc/salt/minion_id: blah.example.com
[DEBUG   ] Reading configuration from /etc/salt/master
[DEBUG   ] The `dmidecode` binary is not available on the system. GPU grains will not be available.
[DEBUG   ] LazyLoaded local_cache.prep_jid
[INFO    ] Runner completed: 20150807203005897069
[DEBUG   ] Runner return: defaultdict(<class 'ordereddict.OrderedDict'>, {})
#

[alisson276]

Same problem with s3 as ext_pillar.

Basically, the problem is with the function get_top() from salt.pillar that not consider ext_pillar for render top. The problem don't occur with compile_pillar (the salt-run pillar.show_pillar calls then) because it consider ext_pillar for the returned dict.

[alisson276]

My workarround was:

def test_top(minion):
    import salt.pillar
    import salt.utils.minions
    id_, grains, _ = salt.utils.minions.get_minion_data(minion, __opts__)
    __opts__['pillar_roots'] = {'base': ['/var/cache/salt/master/pillar_s3fs/base/s3-fs/pillars/base', '/srv/pillar', '/srv/spm/pillar'], 'hml': ['/var/cache/s
alt/master/pillar_s3fs/hml/s3-fs/pillars/hml'], 'dev': ['/var/cache/salt/master/pillar_s3fs/dev/s3-fs/pillars/dev']}
    if grains is None:
        grains = {'fqdn': minion, 'id': minion}

    pillar = salt.pillar.Pillar(
        __opts__,
        grains,
        id_,
        'base')
    top, errors = pillar.get_top()
    return top

[mchugh19]

Just ran into this with git pillars on Salt: 2018.3.0

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[memblin]

Did this issue happen to get moved to a different issue? I just ran across this on 3006.3 when trying to debug a few things with pillar_roots I can salt-run pillar.show_top but it doesn't work if I move that same content into git_pillar. I do get a success True in the return but no top file content in the output.

[pavel-z1]

I have the same issue on salt-master-3007.1