In the past this feature has basically checked returns, pinged minions if they were still running the job, then returning once the job was no longer run remotely. This has caused some issues with race conditions if the minion or master are busy (and the time between minion done, and master recieved gets large).
This changes the behavior of the "wait" mechanism. The intent of this feature is to wait for the job return from all minions the job went to. To accomplish this we fire the job, then check the returns. If the initial returns are what we wanted/expected we break. If it isn't we will ping all targets and see if its still running. If more minions return, we merge them into the list of minions we are waiting for. We will timeout the job once all minions have stopped running the job and TIMEOUT seconds have passed (since the slowest minion)
Conflicts:
salt/client/__init__.py
If you're using salt-call for the first time and don't pass --local, the
message 'Failed to sign in' is kind of confusing. This makes it a little
more clear about what the problem really is.
* Fixed salt tag version matching to also accept, for example, v2014.7. saltstack/salt-bootstrap#464
* Fix the EPEL 7 URL since epel-release is now 7.2
* Distro Support Fixes:
* Updated the URL for EPEL 7
* PIP based installations on Ubuntu 10.04 need setuptools installed
* Arch stopped providing the version information on `/etc/arch-release`
* Complete `salt-api` services checking skips. #450
This is due to our pinging of the minions for job returns, there is a non-zero amount of time between the job showing as "not running" on the minion and showing as recieved by the master. This will only be worse on Syndics-- so I'd recommend not using a 0 timeout value unless you have a small cluser
This is a fix for #15905, the intent being that if you set a timeout it will actually time out. If you pass/set a timeout of 0 it will do the checking of minions etc to determine if the job is running. This seems to be a better compromise since the user/admin can decide wether to have timeouts or not
