[Piuparts-devel] rescheduling broken

[Andreas Beckmann]

On 2013-03-26 08:56, Holger Levsen wrote:
> Hi,
> 
> rescheduling doesnt work as it should, or maybe, it doesnt work as I want it:
> 
> On Montag, 25. März 2013, Cron Daemon wrote:
>> sid: 119/31/0
> 
> what does that mean exactly? 113 passed rescheduled and 31 failed? 

echo "$SECTION: $RCOUNT/$ECOUNT/$UCOUNT"

119 rescheduled, 31 expired, 0 obsolete

rescheduled = put hardlink into recycle/
expire = delete from pass/fail because log is older than expire delay
obsolete = delete from recycle/ because no matching log exists

> I can only see passed logs being rescheduled (and those shouldnt be 
> rescheduled atm. piatti.d.o needs to catch up on squeeze and lenny2squeeze 
> tests and rescheduling sid logs doesnt help at all.

rescheduling does not delete any logs, nothing will be recycled as long
as there is other work to be done. Logs are just *marked* for recycling
(up to a certain limit of logs).

Expiration is the thing that might interfere with your expected behavior
if the "backlog" is larger that what can be processed in between logs
getting recyclied and expired.

> For example, libghc-maths-dev and x86info were both rescheduled, despite no 
> newer version exists.

that's exactly what rescheduling does: prepare retesting of *old* logs
where no new uploads happened

>> sid2experimental: 0/2/0
>> -rw-r--r-- 3 piupartsm piuparts 115106 Mar  9 13:16
>> fail/libc-dev-bin_2.17-0experimental2.log -rw-r--r-- 3 piupartsm piuparts
>> 116085 Mar  9 13:16 fail/locales_2.17-0experimental2.log removed
>> `fail/libc-dev-bin_2.17-0experimental2.log'
>> removed `fail/locales_2.17-0experimental2.log'
> 
> same here, why were those two rescheduled? IMO rescheduling should not happen 
> at all, if there are packages still to be tested.

they were expired

>> Rescheduled 336 logs.
no harm
>> Deleted 167 expired logs.
that causes extra packages needing testing right now
>> Cancelled 47 outdated rescheduling requests.
that's the cleanup if a new package revision comes while the older is
still rescheduled (but it also happens if a log is deleted due to
expiration)

> I hope this is a configuration problem and not one of the code.

On 2013-03-31 11:26, Holger Levsen wrote:
> Hi,
>
> I've disabled rescheduling on piatti for now.

You should have disabled *expiration* only by setting
    expire-old-days = 0
(but keep expire-fail-days at its setting, as expiring fail logs is
useful to identify big blockers by rising block count and getting rid of
"obsolete" failures that have been "replaced" by a more serious one (or
at least one higher up in the dependency tree))

Andreas