Hi, and sorry for late reply (holiday time)! > Since the current retries documentation has not been correct for some
Yes, the documentation (man yum.conf) is incorrect. The retries option effectively applies only to mirrorlist and metalink downloads (before the mirror group object is set up). Then there are no retries, just mirror failovers, limited only by #mirrors. AIUI, this has worked quite well (mostly), but: 1) with 100+ mirrors, we probably retry way too much. 404s on first few mirros imply we should abort. 2) with 1 mirror and 503s, we should retry the same mirror. > time, I think it would be reasonable to adopt the current patch and > add a note in the doc about retry behavior and mirrors. IMO, your patch works fine with singleton repos, but the worst-case scenario of (#mirrors * #retries) retries needs to be changed. Because the replication of metadata and repomd.xml to mirrors is not atomic, Yum may (and does, sometimes) attempt to retrieve URLs that 404 on *every* mirror. This is problematic even in the current implementatation see https://bugzilla.redhat.com/show_bug.cgi?id=726923 but with 200 mirrors and 10 retries, it'd be insane (3). Yes, retrying is a guessing game, but IMO a simple "Do a total of #retry retries, using available mirrors in round-robin" would probably work better, because of 3). > The singleton repo is an important case and one where we > currently seem to have zero network failure tolerance. Definitely. > Note that even in the current patch the retry might not be immediate. > Yum will try all the mirrors before retrying any of them. Unless all > the mirrors fail, there will be no retries of earlier failing > mirrors. + if tries == self.retries: + action['remove_master'] = action['remove'] = 1 The 'remove_master' kills the mirror for good. I'm sure we don't want that, esp. for 404s. _______________________________________________ Yum-devel mailing list [email protected] http://lists.baseurl.org/mailman/listinfo/yum-devel
