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