b4e49fd8a1
The log streaming system suffers a 10 second delay after a skipped command task because: * when processing the results for the next task, we ensure that the log streams for all of the previous tasks have stopped * when stopping a log stream, we wait for the remote command process to finish before we close the stream * if a log file has not appeared yet, we can't determine if the stream has finished * so we wait 10 seconds for the log to appear before we proceed and terminate the stream regardless. The underlying issue is that the code that terminates the stream does not know whether to expect a log file (the normal case) or not (the case for a skipped task). To correct that, we make a new Streamer class which bundles all of the information about a particular log streamer and which is individually addressable. This way we can stop an individual streamer immediately if it's corresponding task is skipped, or stop all of the streamers with a 10 second grace period in the normal case. Since the behavioral difference is a 10 second delay (but otherwise no change in job output), we can't test the behavioral outcome of this change, but we can exercise the code by ensuring that there are skipped command tasks in the remote stream tests. Change-Id: Id6ee13e5a82aa8fa3a2a0dd293cf99ed5b84347a |
||
|---|---|---|
| .. | ||
| playbooks | ||
| roles | ||
| README | ||
| zuul.yaml | ||
README
test