salt-sproxy: Pillar targeting broken

Describe the bug A Minion cant be targeted by using pillars.

Steps To Reproduce A Minion has the role “core” assigned.

# salt-sproxy cr-edge* pillar.get role
cr-edge01.mydomain.com:
    core

But it cant be targeted using -I parameter of salt-sproxy.

# salt-sproxy --preview-target -I "role:core"
No devices matched your target. Please review your tgt / tgt_type arguments, or the Roster data source

# salt-sproxy -I "role:core" test.ping
No devices matched your target. Please review your tgt / tgt_type arguments, or the Roster data source

Expected behavior The minion responds with “True”.

Versions Report

# salt-sproxy -V
Salt Version:
           Salt: 3001.1
    Salt SProxy: 2020.7.0

Dependency Versions:
        Ansible: Not Installed
           cffi: 1.14.2
       dateutil: 2.7.3
      docker-py: Not Installed
          gitdb: 2.0.5
      gitpython: 2.1.11
         Jinja2: 2.10
     junos-eznc: 2.5.3
       jxmlease: Not Installed
        libgit2: 0.27.7
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
         NAPALM: 3.1.0
       ncclient: 0.6.9
        Netmiko: 3.2.0
       paramiko: 2.7.2
      pycparser: 2.19
       pycrypto: 2.6.1
   pycryptodome: 3.6.1
         pyeapi: 0.8.3
         pygit2: 0.27.4
       PyNetBox: Not Installed
          PyNSO: Not Installed
         Python: 3.7.3 (default, Jul 25 2020, 13:03:44)
   python-gnupg: Not Installed
         PyYAML: 3.13
          PyZMQ: 17.1.2
            scp: 0.13.2
          smmap: 2.0.5
        textfsm: 1.1.0
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.3.1

System Versions:
           dist: debian 10 buster
         locale: UTF-8
        machine: x86_64
        release: 4.19.0-10-amd64
         system: Linux
        version: Debian GNU/Linux 10 buster

Additional context Pillar targeting is also not mentioned here: https://salt-sproxy.readthedocs.io/en/latest/targeting.html

But its part of the “salt-proxy -h” help. Is it generally supported?

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 21 (11 by maintainers)

Commits related to this issue

Attempt to fix the caching issues from #169 — committed to mirceaulinic/salt-sproxy by mirceaulinic 4 years ago
Merge pull request #178 from mirceaulinic/pillar-tgt-b0rk Attempt to fix the caching issues from #169 — committed to mirceaulinic/salt-sproxy by mirceaulinic 4 years ago

Most upvoted comments

That appears to have done it.

Added another test pillar:

root@salt-gbone:~# cat /srv/pillar/shared/test2.sls
config:
  fixed: true

root@salt-gbone:~# cat /srv/pillar/top.sls
base:
  '*':
    - shared.global
  minion1:
    - dummy
    - shared.test
    - shared.test2

and the new data shows up without having to delete the cache:

root@salt-gbone:~# salt-sproxy minion1 pillar.items
minion1:
    ----------
    config:
        ----------
        fixed:
            True
        foobar:
            True
    foo:
        bar
    proxy:
        ----------
        proxytype:
            dummy

root@salt-gbone:~# salt-sproxy minion1 pillar.get config:fixed
minion1:
    True

syntax-terr0r on Oct 9, 2020

The command does not work.

# salt-sproxy --preview-target -C "I@role:core"
No devices matched your target. Please review your tgt / tgt_type arguments, or the Roster data source

Im using salt-sproxy only with the following roster.

root@salt-gbone:~# cat /etc/salt/roster
cr-edge02.mydomain.com:
  grains:
    test: no
cr-edge01.mydomain.com:
  grains:
    test: no

I had to specify the grains-section to get “salt-sproxy -G” working. But thats a different topic, just clarifying why its in there 😃

felskrone on Sep 10, 2020