Bug 851178
| Summary: | yum doesn't prefer private top priority repository | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> | ||||||||
| Component: | yum | Assignee: | Fedora Packaging Toolset Team <packaging-team> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 18 | CC: | awilliam, ffesti, james.antill, maxamillion, packaging-team, tim.lauridsen, zpavlas | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | RejectedNTH | ||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2012-08-31 06:45:02 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Kamil Páral
2012-08-23 12:20:57 UTC
When there's no cached information, the 1st mirror should be used, and if it's faster than the "default_speed" option (1MBps is the default) and does not fail, no other mirror should be ever tried. Could you try adding "failovermethod=priority" to yum.conf? The default value is "roundrobin", and this shuffles mirrors on each run. Normally it does not matter, since the ordering is mostly ignored, but this seems to be a special case. You can use: yum repolist -v fedora updates ...and it will show the first host it will hit. Unless you have the "fastestmirror" plugin installed (or something similar) it should be the highest priority item in the metalink/mirror list. Created attachment 606640 [details] yum output When I do that, it reports Repo-baseurl : http://download.eng.brq.redhat.com/pub/fedora/linux/development/18/i386/os/ (22 more) which is correct, but which is definitely not the mirror that was used for downloading metadata (because it was too slow). Also from the error messages in the output it's clear that other mirrors were used. It is a stock F18 installation, no additional yum plugins used. Ok, found what's really going on. 1) failovermethod=priority, and the fast local mirror is at the beginning of the mirror list (so everything is set up correctly) 2) repomd.xml is fetched, and the first mirror gets used. The file size is 4306b, and it takes anything from 5ms to 120ms to download. Don't know exactly what's causing the lag (it's certainly not the fork/exec/import overhead, probably something on the network layer). Maybe the HTTP server itself does some session tracking, and the 1st request has extra latency, who knows. 3) Normally, small files are assumed to give a poor speed estimates, and don't alter the cached speed much. But when there's *no* prior measurement, this mechanism fails, and the mirror speed is set to what we calculate (718kBps in this case). 4) The default speed of all other mirrors is 1MBps, so they are tried first, before we hit the "fast" one again. I think handling the "first measurement" case specially should fix this- just don't update the speed if it's the 1st measurement, and the file was smaller than 1MB. python-urlgrabber-3.9.1-19.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/python-urlgrabber-3.9.1-19.fc18 Package python-urlgrabber-3.9.1-19.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing python-urlgrabber-3.9.1-19.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-12749/python-urlgrabber-3.9.1-19.fc18 then log in and leave karma (feedback). Zdenek, thank you very much, this update improves the behavior substantially. I tried: $ yum clean all $ rm /var/cache/yum/* -rf $ yum repolist enabled $ yum search asdfasdf $ yum provides asdfasdf $ yum group list $ yum update kernel --disableplugin=presto Everything is downloaded extremely fast, therefore our local mirror is used. However, there is still some glitch for this use case: $ yum clean all $ rm /var/cache/yum/* -rf $ yum makecache Some metadata are downloaded very fast, but some of them are downloaded from different mirrors. According to the interactive console output it seems to be a problem of fedora/group_gz and fedora/other_db (see screenshot). I tried to log the output, but with an output redirection some key information are missing, so the log is not much useful. Please note that that the first use case have no such problems (I executed a lot of search etc commands to make sure all the databases are downloaded). It just happens with yum makecache. Created attachment 607906 [details]
yum interactive mode with makecache
Created attachment 607908 [details]
yum output log with makecache
Our local mirror is mentioned on lines 8 and 24.
Proposing as F18 Alpha NTH. We need to get this into Alpha TCs/RCs in order to be able to test effectively. yum-3.4.3-38.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/yum-3.4.3-38.fc18 python-urlgrabber-3.9.1-20.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/python-urlgrabber-3.9.1-20.fc18 Discussed at 2012-08-29 NTH review meeting. We agreed this isn't really serious enough to rate a post-freeze change to a critical package like yum, and is workaroundable for the single group of users affected. yum-3.4.3-40.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. python-urlgrabber-3.9.1-20.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. |