Hello Johannes, Johannes Schauer [2018-01-12 14:27 +0100]: > My central question: is it totally out of scope for autopkgtest to support > modifying the underlying base image?
IMHO yes, as I laid out in my previous reply. I don't want autopkgtest to get into the business of being a "VM manager", as this just opens a huge ratsnest. There are other tools for this, and autopkgtest should avoid making any assumptions about what's inside a VM that isn't absolutely necessary for running tests, as with every new assumption you limit which kinds of VMs you can use with it. > When I added the autopkgtest backend to sbuild in addition to schroot, I did > this with the long term goal in mind that at some point I could also update > the > sbuild-update program to support the autopkgtest backend. It's not what I would recommend doing actually, as with backends like LXC, lxd, or qemu it's actually more reliable and presumably not even slower to just download a current daily image than upgrading existing ones. With schroots it makes a lot more sense, but there's already mk-sbuild for that job. Of course you can work with upgraded testbeds, but by nature they are less reliable. > Users could then use sbuild-update which would automatically do the right > thing independent of the backend. But if you say that autopkgtest never ever > touches the VM image this feature seems to be impossible to implement. But this just shifts the whole ratsnest into autopkgtest: E. g. what do you do when upgrades fail? Or if the image is not a "classic" full-rpm image, but something like the Ubuntu Touch or snappy images, or has a read-only root, or whatnot? autopkgtest would then need to grow/impose a system for snapshotting (in the VM case) and a backup schema for schroots and LXC containers, etc. None of that is it's core business, and all of that potentially interferes with what the admin does, etc. > So do you really see such a feature totally out of scope for autopkgtest? That's my current gut feeling, yes. That said, if some other maintainer thinks that this is a good idea, I won't veto them, but IMHO it's a rather slippy slope, and prone to become a parallel implementation of libguestfs :-) > Because unless I'm mistaken, I don't think there exists another software > besides autopkgtest which offers a unified interface to such a wide range of > backends. For talking to a testbed, yes. But there is no unified approach/code for updating the original testbed (like making a new LXC image, or applying an overlay to a qemu image, or working with a source: schroot, etc.), or managing revisions or rollback of schroot/lxc/lxd/qemu images, as each backend needs specific ways of dealing with that problem. The two concrete CI system that use autopkgtest today (Debian's debci and Ubuntu's autopkgtest-cloud can restrict that logic to the specific backends that they use, and these are complicated enough already IMHO. So implementing it in autopkgtest would not really be less work than just running a specific thing like sbuild-update or lxc-download'ing a current daily. It would be a lot *more* complicated to try and reimplement all these tools in autopkgtest. Martin
signature.asc
Description: PGP signature
