Proposed Migration - Reference Edition

[Christian Ehrhardt]

...

>
>> ##################
>> ### slurm-llnl ###
>> ##################
>>
>>     mysql-8.0 (8.0.18-0ubuntu3 to 8.0.18-0ubuntu4) in proposed for 4 days
>>         Regressions
>>             slurm-llnl/19.05.3.2-2: s390x (log, history)
>>
>>     freeipmi (1.6.3-1.1ubuntu2 to 1.6.4-3ubuntu1) in proposed for 0 days
>>         Regressions
>>             slurm-llnl/19.05.3.2-2: s390x (log, history)
>>
>> * slurm-llnl
>>   - The gtk+ runs pass, but not the ones with freeipmi or mysql
>>
>> * Possible fix: Maybe trigger a run with the new versions of both
>>   mysql-8.0 and freeipmi together?
>>
>
> I've had some people that wanted slurm to be ok - not on s390x but anyway.
> Since I also have easy s390x access I'll take a look into these.
>

Freeipmi was already fixed by a "blunt" retry and it was affected by
exactly the same issue - so it seems to be a flaky test after all.
On the failing cases package install was fine, but later some node didn't
come up.
I was recreating that in s390x containers but at first it worked.

Then I found the generally suspicious:
69 # slurmdbd needs a little time to initialize its db
70 sleep 5

That always seems like a door to errors, what needs 5 seconds might on a
day with heavy I/O on shared storage be 10 and 2 on another.
I was lowering the sleep to see if this really would trigger the same
symptoms, but it didn't always do so.

Actually, this is a warning but the later output confirms it was working
fine:
4                  true       test  slurmtest          1  COMPLETED      0:0

I have proposed a fix to Debian based on that insight =>
https://salsa.debian.org/hpc-team/slurm-wlm/merge_requests/4
Lets see how that turns out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20191212/0b370f5f/attachment.html>