| *** liuxie is now known as liushy | 04:42 | |
| frickler | corvus: the trixie-arm64 keeps failing due to timeouts, I would support merging the semaphore solution now. we can still revise if people think we need a different solution, but I don't think anything bad will happen just if we make the setup actually produce images? | 09:09 |
|---|---|---|
| frickler | periodic image builds for arm are also constantly failing, so there would be actual benefit if we could make those pass | 09:11 |
| opendevreview | Benjamin Schanzel proposed zuul/zuul-jobs master: markdownlint: Recusively search for md files https://review.opendev.org/c/zuul/zuul-jobs/+/968781 | 12:38 |
| opendevreview | Benjamin Schanzel proposed zuul/zuul-jobs master: markdownlint: Recusively search for md files https://review.opendev.org/c/zuul/zuul-jobs/+/968781 | 12:39 |
| rpittau | hi all! I believe there's a regression in the most recent ubuntu (noble + jammy) ovmf pkg, we've seen our uefi jobs all failing after the upgrade, are you aware of anything related to that? | 13:34 |
| mnasiadka | frickler: semaphore is not really helping a lot, although all that failed on timeout are sort of from the same start time (excluding one) | 14:40 |
| fungi | frickler: mnasiadka: i pushed https://review.opendev.org/968386 to hopefully allow us to work out what the resource bottlenecks look like in the guest for those jobs, so we can get more detailed feedback to osuosl about the problem we're experiencing in hopes they might have a better chance of fixing it | 14:46 |
| mnasiadka | fungi: without an in-depth look trixie-arm64 has iops average in hundreds (740 is the highest number, average looks like 150/200) and trixie on x86 has iops average in thousands (12883 being max, the average around 5000) | 14:52 |
| mnasiadka | But dstat outputs look nice, wasn’t aware of that role | 14:54 |
| fungi | mnasiadka: yeah, that's somewhat indicative, i think what we particularly want to identify is whether there's a sustained write to block during the ~45-minute gap in the logs, that could imply a fsync after the preceeding python process terminates, since that could mean write performance in particular is the delay there | 14:55 |
| mnasiadka | Oh yes, the 45 minute gap in the logs is also interesting | 14:56 |
| fungi | out to some lunch/errands, back soonish | 15:57 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!