salt-ssh does not support compound matching or pillars

[jinglejengel]

Looks like even in the latest, salt-ssh still fails to support compound matching and pillar matching? Is there some reason I'm not catching that this wouldn't work via salt-ssh?

  Target Options:
    Target Selection Options

    -E, --pcre          Instead of using shell globs to evaluate the target
                        servers, use pcre regular expressions
    -L, --list          Instead of using shell globs to evaluate the target
                        servers, take a comma or space delimited list of
                        servers.
    -G, --grain         Instead of using shell globs to evaluate the target
                        use a grain value to identify targets, the syntax for
                        the target is the grain key followed by a
                        globexpression: "os:Arch*"
    -P, --grain-pcre    Instead of using shell globs to evaluate the target
                        use a grain value to identify targets, the syntax for
                        the target is the grain key followed by a pcre regular
                        expression: "os:Arch.*"
    -N, --nodegroup     Instead of using shell globs to evaluate the target
                        use one of the predefined nodegroups to identify a
                        list of targets.
    -R, --range         Instead of using shell globs to evaluate the target
                        use a range expression to identify targets. Range
                        expressions look like %cluster

This would be really nice to have for those looking to run agent-less.

[jfindlay]

@Joeskyyy, thanks for the report. Related to #8516.

[jinglejengel]

@jfindlay Awesome, tried to search the issues before creating this and didn't catch that one (:

Does the salt team have a general ETA for this? Even something like "next release" is fine, just looking at how long I'll have to use some custom fudging in the interim.

[jfindlay]

@Joeskyyy, I'm not sure. We have many things we need to get done for Boron and don't have the resources to work on everything. Help is appreciated if you can contribute.

[jinglejengel]

@jfindlay I'll see if I can hack around for a bit. I've at least got salt-ssh accepting the -C flag, but not actually targeting correctly! (That's totally halfway, right? :P)

Having some trouble understanding how the expr_form is actually passed over to salt.client.ssh, however. I believe it boils down eventually to this little bugger, but hunting through calls to find out how that gets passed is driving me insane. Any guidance you can provide on this would be much appreciated.

Part of me (the naive part, of course) was hoping it was as simple as adjusting TargetOptionsMixIn to ExtendedTargetOptionsMixIn. But then it wouldn't be fun would it? haha

    [root@ip-172-31-62-143 ~]# salt-ssh '*' grains.item os
    local:
        ----------
        os:
            Amazon
    [root@ip-172-31-62-143 ~]# salt-ssh -C 'G@os:Amazon' test.ping
    No hosts found with target G@os:Amazon of type compound


    [root@ip-172-31-62-143 ~]# salt -C 'G@os:Amazon' test.ping
    ip-172-31-62-143.ec2.internal:
        True

[jfindlay]

@Joeskyyy, @basepi is the targeting and the salt-ssh guy. You should ask him.

[basepi]

Here's the real problem: we don't have grains data for minions. That's the number one blocker for extending the targeting options.

The only solution I can think of would be to reach out to all minions in the roster on every command to retrieve their grains data. We could theoretically do it once and cache that data, but we have no way to know if it's correct, as the only thing we know about a server is its hostname, and hostnames move from server to server.

[jinglejengel]

@basepi Ah, that makes more sense then. I'm safely assuming that when I call grains.items from salt-ssh, it's just doing that all inline then eh?

Although, how does the already present -G functionality work if there's no cached grain data? Is that polling every minion?

[basepi]

Interestingly, the -G functionality actually doesn't exist.

Salt-ssh will take the desired expr_form and check if the chosen roster supports it. If it doesn't support it it returns an empty set I think (though I thought it logged the fact as well... Apparently not.)

[jinglejengel]

Oh, well that changes everything then, hmmm...

I guess what we could do, expounding on your idea, is to give salt-ssh users a configurable option to cache or not cache minion grains? I could see a case where people wouldn't need to always fetch new minion data each time.

Something along the lines of:

salt-ssh -G 'os:Amazon' test.ping --flush-minion-cache

This would let the user choose to grab new minion cache from all their minions on their roster if they so chose to (Also via a configurable param in their master.conf, presumably). Heck, maybe even utilising some existing functionality in the saltutil.sync_* functions?

[basepi]

Perhaps. I'm also thinking we don't cache by default, and just fetch the data every time a grains match is chosen. It will add a non-trivial amount of overhead to the command, but will result in fewer user-educating issues down the road.

[jinglejengel]

Does save you a load of github issues, forum, and IRC questions I suppose haha As long as it's configurable I think the people who truly care about that little bit of performance bumping will know what to do. So I'd +1 your version.

To be quite honest, I wouldn't even know where to begin on this scope now. :\

[basepi]

I think this is the scope of the feature request:

1. Implement grains lookup for use in targeting. Should probably be above the roster layer, so all rosters can utilize the grain data.
2. Implement grains caching, off by default, with a way to flush the cache
3. Using the grains lookup/caching, implement grains targeting in the default flat roster
4. Implement compound matching in the flat roster. To do full compound matching, we'd have to also generate pillar before targeting minions, which is more overhead. Maybe don't include pillar in compound matching in the first iteration?

I should note that even with this spec, I don't know when I'll have time to tackle this. It does interest me, but it's hard to work on features when there are so many bugs open....

[stale]

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.

[categulario]

I just ran into this issue while trying to target minions with salt-ssh -G '...'