On Tue, Jun 02, 2020 at 08:14:21AM -0700, Adam Williamson wrote: > On Tue, 2020-06-02 at 14:42 +0000, Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Jun 02, 2020 at 02:52:15PM +0200, Christopher Engelhard wrote: > > > On 02.06.20 14:24, Mattia Verga via devel wrote: > > > > Do you think adding a notice like > > > > "The following command may take some time to work after this update has > > > > been pushed to testing, because the dnf mirrors should synchronize." > > > > would work? It may be not the best way to express that, since I'm not > > > > English mother tongue, so if one has a best phrase let me know and I'll > > > > push a PR to Bodhi. > > > > > > That would be great. > > > > > > Suggestion: > > > > > > "It takes some time for repository mirrors to receive this update. If > > > the above command does not install anything, please wait for mirrors to > > > synchronize and try again. This should normally not take longer than > > > <insert typical sync time>. > > > > That would help. But maybe we should approach the problem from the other > > side: figure out what <typical sync time> is, and then delay posting of this > > message by that much (so that when users get this message, they have a > > good chance that it'll actually work) ? > > We actually "know" this quite well, as long as people use metalinks > (the default) at least: we know (or could know) when we publish the new > metadata checksums after doing an updates-testing push, at which point > the whole checksum system should ensure anyone using metalinks *will* > get the new metadata. Nope. Not quite. If we did that then right after mirrormanager updates every mirror (except the master mirrors) would be old and rejected. Instead mirrormanager has the last _3_ checksums as valid. So, when it updates, it gets a list of mirrors, if they have any of the last 3 it says ok. > But the tricky part I think would be co-ordinating the "update has been > pushed to updates-testing" information with the "metadata has been > updated in mirrormanager" information. Right now I don't think there's > actually a message for that at all, but I don't see any reason there > *couldn't* be. But that message would likely just say "published > updated metadata for repo X" - mirrormanager isn't in a position to > know what's actually *changed* in the repo. There would need I think to > be some kind of agent which sits around listening to both mirrormanager > and bodhi messages and figuring out "these are the updates which > actually went out in this push", and doing the Bugzilla comments. That > would be inherently more complex than a simple "receive message, > publish comment" setup as Bodhi does currently. Yeah, seems possible, but that still doesn't tell you when an update is available for user X. We do have: https://admin.fedoraproject.org/mirrormanager/propagation but that doesn't track updates-testing it looks like. Perhaps we could look at simply no longer mirroring updates-testing and just have everyone hit the master mirrrors? I don't know if thats practical tho. kevin
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
