Salt: [salt-ssh] grains not working

[srkunze]

Is that normal?

>>> salt-ssh minion grains.item osrelease
minion:
    ----------
    osrelease:
        12.3


>>> salt-ssh -G 'osrelease:12.3' test.ping
No hosts found with target osrelease:12.3 of type grain

Version:

>>> salt-ssh --versions-report
           Salt: 2015.5.2
         Python: 2.7.3 (default, Apr 14 2012, 08:58:41) [GCC]
         Jinja2: 2.7.3
       M2Crypto: 0.22
 msgpack-python: 0.4.2
   msgpack-pure: Not Installed
       pycrypto: 2.6.1
        libnacl: Not Installed
         PyYAML: 3.11
          ioflo: Not Installed
          PyZMQ: 14.3.1
           RAET: Not Installed
            ZMQ: 4.0.5
           Mako: Not Installed

[arroyoc]

@srkunze Yes that is correct functionality. Currently the only targeting systems that work in salt-ssh are globbing and PCRE.
You can find more info on this in issue #19649
Let me know if you have any other questions. Thanks for the detailed report.

[srkunze]

Alright. I also see that the documentation was mentioned: http://docs.saltstack.com/en/latest/ref/cli/salt-ssh.html#cmdoption-salt-G

Regarding fixing the docs, do you think this can be implemented somehow? Or is that unrealistic for salt-ssh?

[arroyoc]

@srkunze As of right now it seems unrealistic. One of our developers mentioned "The biggest issue is that because minions are not constantly connected to the master for salt-ssh, the master doesn't have the grains for the target systems. So in order to do something like this we would have to reach out to the minion for its grains before we could do any grains targeting, which makes the call a lot heavier and slower."
I would hope that this would be a feature in the future. It would be convenient to be able to use grains to target minions using salt-ssh.

[ssgward]

@srkunze - we need to change the docs to reflect the correct functionality of salt-ssh in this regard.

[srkunze]

@ssgward That'll be great.

@arroyoc Well, that might be true. I understand that you want to keep the code clean and comprehensible. Furthermore, using old grains can cause inconsistencies.

Idea: I could live with a warning when doing so like this:

>>> salt-ssh -G 'osrelease:12.3' test.ping
WARNING: You are using salt-ssh and targeting by grains.
         Grains are older than 1 day and might have changed.
         You can update the grains-cache by executing
         >>> salt-ssh '*' grains.cache_update

That'll suffice for me. :)

Grains don't change that rapidly (at least from what I can see: os, osrelease and so forth).

[srkunze]

I would like to add that not having this features is like not having an extreme useful feature of salt.

People could easily create a cronjob for salt-ssh '*' grains.cache_update. So, they still are up-to-date and can have the grains targeting.

It's not that one could not live without it, but when you need it, you'll definitely miss it. Unfortunately, you never know that in advance.

[kofware]

Hi. I just spent some time trying to make this work, being misled by the doc.
I see here https://github.com/saltstack/salt/issues/19649#issuecomment-69964527 why it might take more time that we think to get fixed (same parser being used by both commands salt and salt-ssh), but in the meantime could you at least add something like this to the doc:
Currently not working for salt-ssh (maybe with a reference to this issues) ?
Thanks.

[guettli]

What is grains.cache_update? Does it already exist, or was it just an idea?

On my system it is unknown.

I would like to target like this salt-ssh -G 'osrelease:...' test.ping

[srkunze]

@basepi Would you mind a working implementation for salt-ssh? If not, could you point me to the right direction?

[basepi]

I probably will not have time in the near future. If you wanted to investigate this yourself, I could give you some pointers.

There are two types of execution module functions in salt-ssh. The normal ones that just come from salt, and the wrapper funcs. (Often wfuncs in the code). The latter are stored in salt/client/ssh/. The reason they exist is because they require some amount of work master-side. Pillar data, states, etc. This is where we should put grains.cache_update. You'll already have the grains available in the wrapper func (we fetch grains prior to all wrapper function executions), so you should be able to just write them to the salt cache.

Then we'll have to add functionality to the flat.py roster to look up this grain cache and target against it.

[srkunze]

@basepi Thanks. I will look into it. It's a very useful feature we're missing. :)

[jacobhammons]

This is fixed in the docs,
https://docs.saltstack.com/en/latest/ref/cli/salt-ssh.html#target-selection (this section used to list all target types).
https://docs.saltstack.com/en/latest/topics/ssh/index.html#targeting-with-salt-ssh

I'm going to close this since the docs now reflect the current behavior.