Hi, On 09-04-2024 6:23 p.m., Paride Legovini wrote:
* 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.However this simple text based protocol also has advantages: it makes it easy to repurpose the virt servers for other uses, like what sbuild does.
That's exactly what I meant.
These other projects do not need to be written in Python, or we could in principle have a virt-server not written in Python.
Currently all our backends are written in Python, so the requirement to have it already exists. I could imaging (just an idea) that we have a (hopefully small) glue script that connects the new or rewritten backends to the old protocol for users like that.
* 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 agree nowadays ssh is a reasonable common denominator. As you noted below, there are some virt servers where it doesn't apply well, but they are probably special enough to be treated differently.
Obviously if there are too many of those, the value of the redesign drops.
I think standardizing on ssh is desirable, but this implicitly means that we'll have some more specific requirements for the testbed images (in random order: sshd, some sort pubkey authentication, a "normal" (non-root) user, cloud-init to initialize all these things?, ...). We are currently shipping tools to prepare test images (tools/autopkgtest-build*), but at the same time we are very flexible on the image requirements. Should we accept being more strict on this, and state that the virt server are meant to be used to purpose built images? Or should we have a better spec on what the virt servers expect from the image?
What I was thinking (but absolutely open for debate) is that the new virt-servers would be responsible for setting up the sshd-server in their supported testbed and handling the key generation and passing on of the information. But, as you suggested, we could also leave that to the image generators (being them our "own" or otherwise created) and document what we need in the testbed. E.g. we could spec that the ssh key lives somewhere in the testbed, to be picked up by the virt-server which transfers the info to the ssh driver. If we go that route, we would remove quite some logic from the `autopkgtest` code path, into the preparation step, which I think would be good. However, a large price (is this worrying? at first sight it doesn't look like anything bigger than already is exposed) would be that the key is probably going to be shared between all autopkgtest runs that are started from the same template testbed.
Currently autopkgtest-virt-ssh works around this by using the "ssh setup" script, but my impression is that we want to move away from that kind of approach.
So that was my initial idea, but indeed, might be better to transfer as much of that as possible to to the testbed creation phase. I'm wondering how much is possible with those maas and nova setups? I would assume they already do only what's needed.
* make the change to use ssh for communication, without a change of the virt server protocol.Do you think this can be done incrementally, that is: 1. modify the virt-servers we have to use ssh for communication with the testbed systems, keeping it in a common library.
That's what I was thinking indeed. But it's hard to judge where it's better to try and keep steps small and manageable to get results versus the addition work required if we finally reach the end goal.
2. keeping the implementation above, or most of it, also reimplement the autopkgtest<->backend communication protocol. The two problems should be quite decoupled after all, and while I'm convinced that point 2 is good, I am less sure about point 1, for the reasons I stated initially.
I think I miss the point you are trying to make here.
* we could consider supporting the current protocol in parallel, which would enable us to migrate one backend at a time and enable our users to migrate their own backends at their own pace. However, it means we'd need to support two code paths. So the open question is: (how long) do we want to maintain the current protocol. I wonder how many other backends are out there.Are we aware of any other consumer of the virt servers apart from autopkgtest itself and sbuild?
I was not, but last days I learned that reprotest copied our virt servers: https://salsa.debian.org/reproducible-builds/reprotest/-/tree/master/reprotest/virt (documentation ongoing in issue #3)
I think we'll probably want a pure Python implementation of that, written using paramiko.
I have never heard of paramiko. Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
