Easier debugging ideas

[hhorak]

Brain dump of some ideas how to make the debugging easier:

• print docker/podman version at the beginning of the test (plus some other related packages)
• do some performance check at the beginning (how quickly network works by pulling some small image and installing a package; how quickly a container starts) -- seeing bigger numbers might indicate that the issues are caused by infra performance
• add possibility to not dispose a machine immediately -- some message like [keep-alive: 2h] in the github.qkg1.topment could make the machine be kept a little longer after the test is done (see https://plugins.jenkins.io/ghprb/ for how to work with the comments)
• similarly as the point above [debug] could turn on the debug (more verbose) output for the tests

[hhorak]

How the keep-alive could work: A simple solution would be to add sleep to the cleanup script:

$ keep_time=$(echo "${ghprbCommentBody}" | grep -o '\[keep-machine[^]]*\]' | sed -e 's/\[keep-machine:\([^]]*\)\]/\1/')
[ -n "${keep_time}" ] && echo "Keeping the machine $IP alive for ${keep_time}" && sleep "${keep_time}"

Of course this can be enhanced by sending a github.qkg1.topment, tagging the person who added that comment etc...

[praiskup]

Do you want to keep the VM allocated by resalloc alive, or the jenkins
machine? If the former, new resalloc feature will be shipped in v3.0;
you could put the machine into sandbox by --sandbox ... and anyone
(perhaps person doing the debugging) could re-take the machine with
the same --sandbox option (within pre-configured time-limit).

[praiskup]

the docs

[hhorak]

@praiskup wow, that helps, thanks. The original idea was very simple -- the job would wait and thus block the chain (there is a limit of 4 parallel jobs I think) -- so doing it through resalloc would be much better approach.

[phracek]

This would be really awesome. I am a volunteer for testing. :)