I came across this bug. It's a shame that no-one thought to ask me, the original designer of this stuff, what my opinion is. But, now I'm here, I will give it:
IMO the autopkgtest virt server protocol is one of my most under-appreciated inventions. It is not just for autopkgtest. IMO it sbould not be redesigned as suggested in this bug report. Some specific responses: > * runner/autopkgtest talks to the backend with a simple text protocol. > While this enables users to add another backend without changes to > the src:autopkgtest code trivially, the drawback of that is loosing > all nuance of what really is going on on both sides of the > communication. That is particularly bad when unexpected events > happen. All events need handling on both sides, including unexpected > events. Much of this is rather vague. If someone wants to support out-of-sequence events, then a protocol extension should be invented for that. But, what kind of out-of-sequence events? I would like to be involved in the design of such an extension. > * every backend has its own virt server that does the real > communication with the testbed. A result of that is subtle > differences in test results between different backends when they > don't do exactly the same (code easily goes out of sync). This is not accurate. In practice the virt servers all use a common Python library for their implementations. Their behaviour is very similar, except for differences due to the underlying virtualisation setup. Different behaviours when run in different environments are indeed a hazard. If they are troublesome, this could be dealt with by more extensive use of the capabilities/features/restrictions features. > * most backends don't automatically provide a testbed as a user would > see when working on a system. I recall smcv saying words like "user > session", "dbus something-something" and the like. This is a feature that surely could be added, and could become a restriction. > * unify the communication with test beds via ssh. This ensures that > the environment is much more likely to be the same across the > different backends and also ensures the right session. I do not agree with this. In particular, this would make it very awkward to implement any backend that doesn't want to start daemons, expose itself over localhost, etc., including -null, -virt, -chroot, -unshare, etc. > * 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 do not agree with this. The interface should be language-agnostic. > Are we aware of any other consumer of the virt servers apart from > autopkgtest itself and sbuild? tag2upload is using it too. I have used it in other more ad-hoc situations. By its nature, there may be out-of-Debian users. I do agree that the code in the autopkgtest test runner is tangled. It was tangled when I wrote it and I think it has become worse since then. I think this is orthogonal to the virt backend protocol. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
