<div dir="ltr">Upon even further reflection, it is indeed a bug, and I have now fixed it in MM upstream, and in FI production. The fix should be evident within a few hours.<div><br></div><div><div>commit b4d6a13208c37db15158876606530bd33eb0d1b7</div>
<div>Author: Matt Domsch <<a href="mailto:matt@domsch.com">matt@domsch.com</a>></div><div>Date: Sun Dec 22 14:10:13 2013 -0600</div><div><br></div><div> default directories to ordered_mirrorlist = True</div><div>
<br></div><div> Reported by two private mirror operators on mirror-list-d and</div><div> privately, mirror operators using metalinks were getting _only_ their</div><div> mirror returned in the metalink, not theirs, plus several fallbacks.</div>
<div> When their mirrors then were not working or not up-to-date or not</div><div> reachable, yum would fail because there were no more mirrors to try.</div><div><br></div><div> Complicating things, when viewed using mirrorlist/ rather than</div>
<div> metalink/, mirrorlist returned a long list, while metalink didn't.</div><div><br></div><div> The proximate cause is that mirrorlist/ looks at Repository pointers</div><div> into a directory, where the ordered_mirrorlist=True value is set on</div>
<div> the corresponding Version object for that Repository. However,</div><div> metalink/ was looking one directory deeper, at the repodata/</div><div> directory, which was _never_ being treated as</div><div> ordered_mirrorlist=True. This causes the path through</div>
<div> mirrorlist_server.py:do_mirrorlist() to take the !ordered_mirrorlist</div><div> path, which was intended only for long-obsolete product Versions</div><div><br></div><div> We should delete the whole !ordered_mirrorlist codepath, but won't do</div>
<div> so at this time.</div><div><br></div><div> Instead, we'll solve the immediate problem with the smallest possible</div><div> change, default ordered_mirrorlist=True for all directories, and only</div><div>
historical (non-metalink-using) Versions may set it to False.</div><div><br></div><div>diff --git a/server/mirrormanager/mirrorlist.py b/server/mirrormanager/mirrorlist.py</div><div>index e67c9c2..3618c39 100644</div>
<div>--- a/server/mirrormanager/mirrorlist.py</div><div>+++ b/server/mirrormanager/mirrorlist.py</div><div>@@ -124,7 +124,7 @@ def populate_directory_cache():</div><div> continue</div><div><br></div><div> if directoryname not in cache:</div>
<div>- cache[directoryname] = {'global':set(), 'byCountry':{}, 'byHostId':{}, 'ordered_mirrorlist':False, 'byCountryInternet2':{}}</div><div>+ cache[directoryname] = {'global':set(), 'byCountry':{}, 'byHostId':{}, 'ordered_mirrorlist':True, 'byCountryInternet2':{}}</div>
<div><br></div><div> repo = directory_repo_cache.get(directory_id)</div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Dec 21, 2013 at 3:15 PM, Matt Domsch <span dir="ltr"><<a href="mailto:matt@domsch.com" target="_blank">matt@domsch.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">This is actually working as designed, though I think the design is flawed. :) Private mirrors for a netblock get presented, if MM thinks they have the requested content and are up to date. The rest of the list then isn't presented. However, if that mirror turns out to not be working or reachable or not up to date, there are no fallbacks to use.</p>
<p dir="ltr">I will consider a proper fix to the design and then implementation but wont rush to fix it as if it were a newly introduced bug.</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Dec 21, 2013 8:00 AM, "Matt Domsch" <<a href="mailto:matt@domsch.com" target="_blank">matt@domsch.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">There's some bug related to metalinks specifically (which is what yum is using). I likely introduced it with the MM 1.4.3 upgrade this week. This is the second report of failure, and I can clearly see that metalinks only are returning a single mirror for some users, while mirrorlist returns the whole list as expected. It looks to be only for hosts that fall within a netblock of a private mirror.<div>
<br></div><div>I am travelling with my family today, so offline mostly. I'll look at it and resolve ASAP.</div><div><br></div><div>Thanks,<br></div><div>Matt</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Fri, Dec 20, 2013 at 7:09 PM, Albert Wang <span dir="ltr"><<a href="mailto:wang@polymathanalytics.com" target="_blank">wang@polymathanalytics.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi everyone,<br>
<br>
Sorry if I'm sending the question to the wrong mailing list, but I'm hoping someone can help me with my problem:<br>
<br>
I have a for-home private repository that I set up, which contains most, but not all the rpm packages, for quicker updates.<br>
It has been working fine until a week or so ago, where, essentially, the call:<br>
curl -s "<a href="https://mirrors.fedoraproject.org/metalink?repo=updates-released-f19&arch=x86_64&ip=98.113.159.63" target="_blank">https://mirrors.fedoraproject.org/metalink?repo=updates-released-f19&arch=x86_64&ip=98.113.159.63</a>"<br>
<br>
now only returns one private repo site (without the full list of other alternatives). This causes problems, since I filtered out certain devel packages.<br>
Is there a policy/implementation change that I am not aware of?<br>
<br>
Thank you very much for your time. Happy holidays!<br>
Albert<br>
<br>
<br>
<br>
--<br>
<br>
</blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>