[Yum-devel] yum does not retry on 503 errors

[Mike McLean]

In our Koji system, we've had a number of issues with yum failing on
503 errors, despite the explicit retries=20 that koji places in the
yum.conf. Looking further I found that there are several barriers in
the code to such retries:
1) urlgrabber does not distinguish 503s from other http errors. they
are lumped together
2) urlgrabber does not retry on http errors by default and yum does
not alter this
3) the failure callback that yum gives to urlgrabber /always/
re-raises the exception, preventing any possible retries that that
level

I found #3 the most surprising since yum goes to the trouble of
passing the retry option to urlgrabber

503 errors are usually meant to be retried. Possibly there are other
http statuses that should be retried as well.

I've attached a overly simple patch to urlgrabber that does solve my
immediate issue, but I'm not sure if it's the right fix overall. I'd
be happy to work on a better fix, but I thought I would solicit
feedback/advice first.

I figure a more robust solution would likely:
a) allow both immediate retries within the _retry function and
postponed retries somewhere in the MirrorGroup class
b) honor the retry-after header, possibly by pushing the mirror to the
back of the list
c) retry other temporary http errors (e.g. 420, 429, 509)
d) either add a separate callback for retries or pass more useful
retry status information to the existing callbacks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-retry-on-503-errors.-don-t-callback-on-retries.patch
Type: application/octet-stream
Size: 1432 bytes
Desc: not available
URL: <http://lists.baseurl.org/pipermail/yum-devel/attachments/20120626/ff15b755/attachment.obj>