Bug#886332: autopkgtest-virt-qemu: how to make persistent dist-upgrades

[Martin Pitt]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20180127/225e7bd3/attachment.sig>