Hi Paul, On 2024-04-07 16:42, Paul Gevers wrote: > The following issues have come up several times over the years. I > propose to discuss them in one place (this bug report) to define the > solution strategy. I haven't gone through all the details myself, so I > might be thinking in the wrong direction, please correct me if you think > so. Please also voice agreement, if not on the details, then on the > general concept.
I'm not a maintainer but I use autopkgtest a lot. I hope it's OK if I contribute input. I generally agree with all of what you said, and would add the following: > * [mostly orthogonal] currently the autopkgtest code has a lot of state > in a non-Pythonic way. Reasoning about what goes on and debugging > autopkgtest code flow is non-trivial. It is indeed very difficult to keep track of what's going on. A lot of state is kept in/communicated through globals, and it can be challenging to remember which role the running threads are playing, and in which relationship. (smcv put this into historical context once.) > Solution direction > ================== > * handle communication between runner/autopkgtest and the virt servers > and the ssh driver via Python classes instead of the text based > protocol. Do this in a "plugin" friendly way such that backends can > still easily be used without changes to src:autopkgtest. I would add to this that testbed I/O and test I/O could benefit from separate communications channels. Example: the Debian ROCm Team requested the --timeout-poweroff option for the QEMU backend because the hardware we pass in needs a clean shutdown procedure. But it is not possible to trigger a shutdown when a test is running, because on the I/O channel is being waited on for output. So a timeout still ends with a SIGTERM of the testbed. Best, Christian
