On Fri, Feb 04, 2022 at 11:31:49AM +0000, Ian McInerney via devel wrote: > On Thu, Feb 3, 2022 at 7:41 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > On Thu, Feb 03, 2022 at 06:38:11PM +0000, Ian McInerney via devel wrote: > > > > > > I guess it was a mirror caching issue. I tried again just now and it > > picked > > > up the update just fine. I didn't think the updates-testing repo was > > > mirrored though, but it is very annoying that the mirror sync and the > > push > > > to updates-testing apparently aren't synchronized, leading to a large lag > > > there. > > > > yes, updates-testing is mirrored just like updates. > > > > Sadly there's not too much we can do about the sync time, since mirrors > > are free to sync as ofter or inoften as they like. ;( > > > > It's possible that updates-testing doesn't get that much traffic these > > days and we could look at un-mirroring it somehow. Everyone seems pretty > > used to it by now however and you can get the updates from koji or from > > bodhi directly too. > > >From a user experience perspective, the mirror lag time on it is very > annoying. When the update is pushed to testing, Bodhi posts a comment in > the associated Bugzilla saying that you should "soon" be able to install > the update using the relevant DNF command. In my opinion, having to wait 18 > hours before that command works (and continually having to try that command > throughout the day to see when it will start working) is very annoying from > the perspective of someone who wants to test the fix to a bug they are > affected by/reported. > > Can we figure out how much traffic updates-testing is actually getting > currently to see if it can be unmirrored? In my mind, it would seem that > the fact updates live inside updates-testing for a very short time (on the > timescale of days) before being moved to normal updates, and the fact it is > not enabled by default, would make me think it is probably low traffic in > comparison. > > Alternately, is there an option in DNF to automatically use the mirror that > was updated most recently, even if it isn't the fastest/geographically > closest? The behaviour you are seeing is actually a 'feature'. Once the primary mirror is updated we include older (<mm0:alternate>) checksums in addition to the newest checksum in the metalink. The main reason for this feature is that we want to give mirrors time to sync and we want to avoid all clients using the primary mirror for the first few hours of new content. For most things this is an acceptable compromise. For your situation it is indeed not helpful. Currently we are including older checksums in the metalink for three days. This number could be reduced to maybe two. Another approach would be if DNF could be told to ignore '<mm0:alternate>' checksums for repositories like updates-testing with a new configuration option. Adrian
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
