Allows overriding 'timeout' and 'gather_job_timeout' to 'manage.up' runner call

[meaksh]

What does this PR do?

This PR allows overriding timeout and gather_job_timeout parameters to manage.up and manage.status runners. These two parameters are set in our master configuration with a high value, as we want to wait by default for jobs that takes long to execute:

timeout: 120
gather_job_timeout: 120

When dealing with an scenario where some minions are down, if we execute manage.up runner to check for minions that are up and running, it will end up after reaching the two timeouts. This makes manage.up runner unusable as presence mechanism because we cannot get a response in some short and fixed time.

With this PR, we are able to call manage.up runner passing timeout and gather_job_timeout parameters which are used to perform the upcoming test.ping job that the runner is going to trigger.

This way we can get a quick response of manage.up runner in case of unreachable minions. Even if we call the runner via API.

Previous Behavior

$ time salt-run manage.up
- headref-minsles12sp2.tf.local

real	4m1.052s
user	0m3.729s
sys	0m0.264s

New Behavior

$ time salt-run manage.up timeout=2 gather_job_timeout=1
- headref-minsles12sp2.tf.local

real	0m3.964s
user	0m0.693s
sys	0m0.119s

Tests written?

No

What do you think about this?

I also tried with manage.present runner but it doesn't fit well in our scenario. Is there another quick way to check for the actual presence of minions in a context with unreachable minions?

Any feedback or opinions are more than welcome! 😄
Thanks

/cc @moio

[ghost]

@meaksh, thanks for your PR! By analyzing the history of the files in this pull request, we identified @0xDEC0DE, @cachedout and @cvrebert to be potential reviewers.

[cachedout]

This seems totally reasonable. I like it.

[meaksh]

Great @cachedout. Do you think we should also allow those parameters for the general test.ping command?

BTW there're some conflicts merging this PR forward to 2016.11 branch. If needed, I can do another PR with the fixed version for 2016.11, or you can just ping me to verify the resolution.

[cachedout]

@meaksh If you want to do it to test.ping I have no objection so long as it's done as a kwarg.

[rallytime]

@meaksh If you have the time to put a PR together for 2016.11, that would be awesome. The merge conflict isn't too terrible, but a little bit trickier than normal. That way I won't miss something in resolving the conflict.

[meaksh]

@rallytime - Here it is the PR for 2016.11 branch: #40072