Minion did not return while using compound matching with custom grain.

[roflmao]

Description of Issue/Question

While using compound matching i dont get response from minion. (it matches the host)

root@salt-001:~# salt -v -C G@facter_role:docker test.ping
Executing job with jid 20160815103816026593
-------------------------------------------

dn-080.X.no:
    Minion did not return. [No response]

-------------------------------------------
Summary
-------------------------------------------
# of minions targeted: 1
# of minions returned: 0
# of minions that did not return: 1
# of minions with errors: 0
Minions not responding: dn-080.X.no
-------------------------------------------
root@salt-001:~# salt dn-080* test.ping
dn-080.X.no:
    True

-------------------------------------------
Summary
-------------------------------------------
# of minions targeted: 1
# of minions returned: 1
# of minions that did not return: 0
# of minions with errors: 0
-------------------------------------------

Setup

2016.3.2 with Ubuntu 16.04 master and Ubuntu 12.04 minion.

Versions Report

Master:

root@salt-001:~# salt --versions-report
Salt Version:
           Salt: 2016.3.2

Dependency Versions:
           cffi: 1.5.2
       cherrypy: Not Installed
       dateutil: 2.4.2
          gitdb: 0.6.4
      gitpython: 1.0.1
          ioflo: Not Installed
         Jinja2: 2.8
        libgit2: 0.24.0
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: 1.0.3
   msgpack-pure: Not Installed
 msgpack-python: 0.4.6
   mysql-python: Not Installed
      pycparser: 2.14
       pycrypto: 2.6.1
         pygit2: 0.24.0
         Python: 2.7.12 (default, Jul  1 2016, 15:12:24)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 15.2.0
           RAET: Not Installed
          smmap: 0.9.0
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.1.4

System Versions:
           dist: Ubuntu 16.04 xenial
        machine: x86_64
        release: 4.4.0-34-generic
         system: Linux
        version: Ubuntu 16.04 xenial

Minion:

oot@dn-080:~# salt-call --versions-report
Salt Version:
           Salt: 2016.3.2

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 1.5
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.6
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: 0.7.0
   msgpack-pure: Not Installed
 msgpack-python: 0.3.0
   mysql-python: 1.2.3
      pycparser: Not Installed
       pycrypto: 2.6.1
         pygit2: Not Installed
         Python: 2.7.3 (default, Jun 22 2015, 19:33:41)
   python-gnupg: Not Installed
         PyYAML: 3.10
          PyZMQ: 14.0.1
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.0.5

System Versions:
           dist: Ubuntu 12.04 precise
        machine: x86_64
        release: 3.13.0-53-generic
         system: Linux
        version: Ubuntu 12.04 precise 

[anitakrueger]

I don't think it is a different problem. Actually what I'm seeing is exactly what @roflmao described at the very top. I think the problem just got a little more refined along the way. I just couldn't believe that nobody would have looked at this since 2016, because it does sound like a very basic issue.

[djha-skin]

@anitakrueger just wanted here to highlight my comment in #21986 on how to work around grain targeting, it's less important now than it used to be when it comes to the mine because they fixed this (for the mine only) in 2019.2.0 with the greedy flag, but it is also applicable in other contexts as well. EDIT: I thought the greedy flag fixed this but it looks like it doesn't, that mine issue (the root cause of which is the same as the root cause of this issue) is still being commented on relatively recently.

[djha-skin]

Further reading:

37261

33730

[Ch3LL]

@anitakrueger I verified your issue is fixed on the 2019.2.1 branch, so it will be included in the 2019.2.1 release. Your issue is different from the reported issue here, so we will not be able to close this as its a feature that needs to be added. Here is my verification test case:

v2019.2.0

(salt-py2) ➜  salt git:(0ca04ffbeb) sudo salt '*'  grains.setval roles webserver3
newrecipe:
    ----------
    roles:
        webserver3
(salt-py2) ➜  salt git:(0ca04ffbeb) sudo salt -G 'roles:webserver3' test.ping
newrecipe:
    Minion did not return. [No response]
ERROR: Minions returned with non-zero exit code
(salt-py2) ➜  salt git:(0ca04ffbeb) 

2019.2.1 branch

(salt-py2) ➜  salt git:(c56fbb0f94) sudo salt '*'  grains.setval roles webserver5
newrecipe:
    ----------
    roles:
        webserver5
(salt-py2) ➜  salt git:(c56fbb0f94) sudo salt -G 'roles:webserver5' test.ping
newrecipe:
    True
(salt-py2) ➜  salt git:(c56fbb0f94) 

[Ch3LL]

Forgot to mention @anitakrueger if you could verify on the 2019.2.1 branch to ensure I am correct.

[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.

[bluesliverx]

This is definitely still a problem and should not be marked as stale. We've ended up working around it in another way (query our CMDB to know which servers to target before calling salt), but this is rather lame and I would much rather use Salt to do it completely since it has all of the information it needs.

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[twangboy]

@roflmao Could you verify that this is still a problem with 3006.2?

[twangboy]

Closing this due to age, the old version of Salt and Python 2. Can you retest this with the latest release of Salt 3006.2 and if still an issue, please open a new issue, which will have metrics in tracking issues.