retry Bodhi request if server returns HTTP 5xx
ClosedPublic

Authored by garretraziel on Sep 30 2014, 9:17 AM.

Details

Summary

Because Bodhi server sometimes returns Internal Server Error
(HTTP 500), BodhiUtils retries its request N-times.

Test Plan

py.test testing/ (added two tests for query retries)

Diff Detail

Repository
rLTRN libtaskotron
Branch
arcpatch-D239_1
Lint
No Linters Available
Unit
No Unit Test Coverage
garretraziel retitled this revision from to retry Bodhi request if server returns HTTP 5xx.Sep 30 2014, 9:17 AM
garretraziel updated this object.
garretraziel edited the test plan for this revision. (Show Details)
garretraziel added reviewers: tflink, kparal.
garretraziel edited the test plan for this revision. (Show Details)Sep 30 2014, 9:49 AM
tflink requested changes to this revision.Sep 30 2014, 1:48 PM

Overall, a good start.

I'm wondering if it would be better to broaden this so that failed requests are retried instead of just retrying on 500s. Any other thoughts?

libtaskotron/bodhi_utils.py
59–75

please use a more descriptive var name than i. Something like num_retries or retries would be better

70

why not use e.code != 500 here instead of < and >?

This revision now requires changes to proceed.Sep 30 2014, 1:48 PM

About that retrying on all errors - what about when server returns 404?

libtaskotron/bodhi_utils.py
70

That's because Kamil checked it and server sometimes returns 500, sometimes 503. I was not sure whether it can return other errors, so it retries it on all 500 Server errors.

tflink added a comment.Oct 1 2014, 3:03 PM

About that retrying on all errors - what about when server returns 404?

I suppose that 5XX errors are the ones that we're most interested in but on the other hand, why would retrying on 404s be a bad thing?

I'm fine with either approach, though. This has the most important cases covered

libtaskotron/bodhi_utils.py
70

oh, I see now. sorry - read too quickly

tflink commandeered this revision.Oct 6 2014, 2:52 PM
tflink edited reviewers, added: garretraziel; removed: tflink.

This needs to get done today, taking over revision so I can send an updated patch

tflink updated this revision to Diff 668.Oct 6 2014, 2:53 PM

Getting rid of the i in bodhi_utils, changing name to explicitly state max retries

kparal added inline comments.Oct 6 2014, 3:01 PM
libtaskotron/bodhi_utils.py
46

If you want to make it pretty, you can use

``bodhi_request_max_retries``-times
68

The defensive approach here would be to use >= instead of ==.

tflink updated this revision to Diff 669.Oct 6 2014, 3:14 PM
  • fixing doc and retry comparison from comments in review
mkrizek added a subscriber: mkrizek.Oct 6 2014, 3:52 PM

Just one nitpick.

libtaskotron/bodhi_utils.py
75

The message is somewhat confusing though. If the server is always unavailable we get:
Got HTTP 0 response from server, retrying (1 from 3)...
Got HTTP 0 response from server, retrying (2 from 3)...
*re-raise the exception*

and that's it, where's (3 from 3)? :) Sure, we try querying the server three times, but the message is confusing. What about changing the message to something like 2 retries remaining?

tflink updated this revision to Diff 671.Oct 7 2014, 5:54 AM
  • changing retry message and comparisons around slightly
garretraziel requested changes to this revision.Oct 7 2014, 7:51 AM

Otherwise LGTM. I will commandeer this revision, wait for kamil's feedback and push it.

libtaskotron/bodhi_utils.py
68

I think that there is off-by-one error. xrange(1,X) generates numbers from 1 to X-1, so retry_num will never be equal to max_retries. I think that running tests confirms it.

This revision now requires changes to proceed.Oct 7 2014, 7:51 AM
garretraziel commandeered this revision.Oct 7 2014, 7:52 AM
garretraziel edited reviewers, added: tflink; removed: garretraziel.
garretraziel updated this revision to Diff 672.Oct 7 2014, 7:54 AM
  • correction of off-by-one error
kparal accepted this revision.Oct 7 2014, 7:59 AM

Seems good.

This revision is now accepted and ready to land.Oct 7 2014, 7:59 AM
mkrizek accepted this revision.Oct 7 2014, 8:07 AM
mkrizek added a reviewer: mkrizek.
garretraziel closed this revision.Oct 7 2014, 8:27 AM