Re: yum-presto occasionally goes into eternal loop looking for deltas
On Thu, 7 Jan 2010, James Antill wrote:
On Thu, 2010-01-07 at 21:19 +0200, Jonathan Dieter wrote:
On Thu, 2010-01-07 at 20:44 +0200, Pekka Pietikainen wrote:
Presto is one of the best things ever, but occasionally it ends up not
finding the delta files from any of the mirrors in the mirror list and just
loops through them without making any progress. --disablepresto works
a-ok, I think yum clean all; yum update also did the trick once.
Still, this can probably be made a lot better. It shouldn't do that even if the
mirrors
are out-of-sync. Maybe add some logic that just disables
presto if the deltas are nowhere to be found after a few attempts? Anyone
else even see this happen?
Yeah, see https://bugzilla.redhat.com/show_bug.cgi?id=540140. To
summarize, the problem is that new updates have been pushed to the
server between the time you loaded primary.sqlite and prestodelta.xml.
When you run 'yum clean metadata' or 'yum clean all' it removes the
outdated cached primary.sqlite and downloads the newer version.
The bug has been closed as WONTFIX because there have only been a few
reports; I wouldn't mind revisiting that decision if someone has a
clever way of fixing it. (And I'm not convinced that checking n mirrors
and then giving up is the solution.)
The plugin could require yum = 3.2.25, and then do something like (in
config or prereposetup):
for repo in repos:
repo.mdpolicy.append('prestodelta')
...which would auto download presto MD when yum gets new repomd/primary.
People might complain though :) ... another kind of fix would be for the
plugin to call .cleanExpireCache() if the MD fails to download.
The nice server side fix is to keep around more than one complete set
of MD (possible now we have unique MD filenames), so there would have to
be two updates within the client side cache timeout. But I'm not sure
how easy that is.
But not all the drpms would be kept so if a largish number of them
changed
-sv
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
yum-presto occasionally goes into eternal loop looking for deltas
Presto is one of the best things ever, but occasionally it ends up not finding the delta files from any of the mirrors in the mirror list and just loops through them without making any progress. --disablepresto works a-ok, I think yum clean all; yum update also did the trick once. Still, this can probably be made a lot better. It shouldn't do that even if the mirrors are out-of-sync. Maybe add some logic that just disables presto if the deltas are nowhere to be found after a few attempts? Anyone else even see this happen? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto occasionally goes into eternal loop looking for deltas
On Thu, 2010-01-07 at 20:44 +0200, Pekka Pietikainen wrote: Presto is one of the best things ever, but occasionally it ends up not finding the delta files from any of the mirrors in the mirror list and just loops through them without making any progress. --disablepresto works a-ok, I think yum clean all; yum update also did the trick once. Still, this can probably be made a lot better. It shouldn't do that even if the mirrors are out-of-sync. Maybe add some logic that just disables presto if the deltas are nowhere to be found after a few attempts? Anyone else even see this happen? Yeah, see https://bugzilla.redhat.com/show_bug.cgi?id=540140. To summarize, the problem is that new updates have been pushed to the server between the time you loaded primary.sqlite and prestodelta.xml. When you run 'yum clean metadata' or 'yum clean all' it removes the outdated cached primary.sqlite and downloads the newer version. The bug has been closed as WONTFIX because there have only been a few reports; I wouldn't mind revisiting that decision if someone has a clever way of fixing it. (And I'm not convinced that checking n mirrors and then giving up is the solution.) Jonathan signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto occasionally goes into eternal loop looking for deltas
On Thu, 2010-01-07 at 21:19 +0200, Jonathan Dieter wrote:
On Thu, 2010-01-07 at 20:44 +0200, Pekka Pietikainen wrote:
Presto is one of the best things ever, but occasionally it ends up not
finding the delta files from any of the mirrors in the mirror list and just
loops through them without making any progress. --disablepresto works
a-ok, I think yum clean all; yum update also did the trick once.
Still, this can probably be made a lot better. It shouldn't do that even if
the mirrors
are out-of-sync. Maybe add some logic that just disables
presto if the deltas are nowhere to be found after a few attempts? Anyone
else even see this happen?
Yeah, see https://bugzilla.redhat.com/show_bug.cgi?id=540140. To
summarize, the problem is that new updates have been pushed to the
server between the time you loaded primary.sqlite and prestodelta.xml.
When you run 'yum clean metadata' or 'yum clean all' it removes the
outdated cached primary.sqlite and downloads the newer version.
The bug has been closed as WONTFIX because there have only been a few
reports; I wouldn't mind revisiting that decision if someone has a
clever way of fixing it. (And I'm not convinced that checking n mirrors
and then giving up is the solution.)
The plugin could require yum = 3.2.25, and then do something like (in
config or prereposetup):
for repo in repos:
repo.mdpolicy.append('prestodelta')
...which would auto download presto MD when yum gets new repomd/primary.
People might complain though :) ... another kind of fix would be for the
plugin to call .cleanExpireCache() if the MD fails to download.
The nice server side fix is to keep around more than one complete set
of MD (possible now we have unique MD filenames), so there would have to
be two updates within the client side cache timeout. But I'm not sure
how easy that is.
--
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.26
http://yum.baseurl.org/wiki/YumMultipleMachineCaching
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
