yum-presto occasionally goes into "eternal" loop looking for deltas

[Seth Vidal]

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