Adam Williamson 0396d70de0 handle errors while waiting for compose smartly ... Summary: So the first attempt to use the waiting stuff in production failed because, at some point, koji_done got a socket.error from the server. Not sure if that was a Koji outage or some kind of rate control, but even if it's rate control and we need to tweak the wait interval, this seems advisable: we shouldn't die the first time we hit any kind of error while waiting, we should retry a few times first (with increasingly long delays between the retry attempts). I know bare except clauses are BAD, but I think it's OK here as we can't really cover every possible exception which might get raised in any module during a 'go hit a server and do a bunch of stuff' operation, and if the error keeps happening we *are* going to raise it eventually. Test Plan: Check I didn't break the 'normal' case, and try causing an error to appear somehow (e.g. disconnect from the network or hack up the 'client' instantiation in fedfind to use the wrong URL) and see if the error handling works as intended. Reviewers: garretraziel, jskladan Reviewed By: garretraziel, jskladan Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D532		2015-08-27 15:51:15 -07:00
..
conf_test_suites.py	add 32bit disk creation	2015-08-27 13:48:25 +02:00
openqa_trigger.py	handle errors while waiting for compose smartly	2015-08-27 15:51:15 -07:00
report_job_results.py	report_job_results: handle cancelled jobs	2015-08-10 11:10:57 -07:00