saltstack
salt will respond with an empty list of minions if minions are connected to a syndic master
If minion1-3 are connect directly to a master where the API is running, globbing isn't a problem.
pepper --fail-if-incomplete minion* test.version
{u'return': [{u'jid': u'20170727125430772351', u'minions': [u'minion1', u'minion2', u'minion3']}]}
or
pepper --fail-if-incomplete minion1 test.version
{u'return': [{u'jid': u'20170727125430772351', u'minions': [u'minion1']}]}
however, if minions are connected to a syndic master, globbing does not work and therefore using the polling option always fails because the poller is waiting if set(ret_nodes) == set(nodes) which never happens. you end up hitting the timeout every time
pepper --fail-if-incomplete minion1 test.version
{u'return': [{u'jid': u'20170727125430772351', u'minions': []}]}
output:
return: {u'minion1': u'2016.11.1'}
exit: None
return: {u'Failed': [u'minion1']}
exit: 1
it would appear this happens to all expr_forms with any minion connected to a syndic.
Thanks for filing this. I can't think of a way to solve this without also subscribing to Salt's event bus (meaning this is tricky to do with only the Python 2 stdlib; we'd need to pull in a dep).
with a syndic in the topology, can the minion list returned by influenced by configuring external minion data cache?
if that is the case, it would seem that solution is easier to handle then rigging up something to listen in on the event bus.
Interesting question. That addition has many potential implications. I'm not sure this one has been explored yet. Offhand, we'd need keys, grains, and pillar from each master available to perform the matching logic locally.
Talking with @UtahDave i dont think it would help in this situation. However, he did ID the issue here https://github.com/saltstack/salt/pull/36318
i think once this is solved this may resolve this problem. i'm going to do some testing here.
