Bug#886332: autopkgtest-virt-qemu: how to make persistent dist-upgrades
Hi, On 2019-11-11 00:01, Johannes Schauer wrote: >> Johannes, have you found a solution in the meanwhile? I just stumbled over this bug. Package sbuild-qemu has the 'sbuild-qemu-update' utility which dist-upgrades images created by autopkgtest-build-qemu. There's also an sbuild-qemu-boot utility in case you want to interactively do something with the image. Best, Christian
Bug#886332: autopkgtest-virt-qemu: how to make persistent dist-upgrades
Hi Francesco, Quoting Francesco Poli (2019-11-10 16:38:56) > On Sat, 27 Jan 2018 22:45:37 +0100 Martin Pitt wrote: > > [...] > > Johannes Schauer [2018-01-12 14:27 +0100]: > [...] > > > 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. > > Hello, > I am a "passerby" with respect to this bug report, so to speak. > > I would like to ask a question: Martin, do I understand correctly that > you are saying that recreating the QEMU/KVM testbed from scratch (with > autopkgtest-build-qemu) is faster than upgrading an existing QEMU/KVM > testbed? Despite the debootstrap step, which is notoriously slow?!? > > Johannes, have you found a solution in the meanwhile? well, my favourite solution is of course if autopkgtest would gain a functionality to disable the read-only overlay and thus become capable of making persisting changes to the backend. But I understood that Martin prefers to rather re-create the underlying backend rather than upgrading it. He does not seem to be alone either. You might find the following thread on debian-devel interesting to read: https://lists.debian.org/20191007102902.ga9...@espresso.pseudorandom.co.uk I don't have enough free time to maintain an autopkgtest fork or plugin that does what I want so instead I went the opposite way and created a tool that can do the "re-bootstrap, don't upgrade" thing reasonably fast. I wrote to you about that in #944485. So basically my solution is to work around this bug by using mmdebstrap to always re-create my base image instead of upgrading it. Thanks! cheers, josch signature.asc Description: signature
Bug#886332: autopkgtest-virt-qemu: how to make persistent dist-upgrades
On Sat, 27 Jan 2018 22:45:37 +0100 Martin Pitt wrote: [...] > Johannes Schauer [2018-01-12 14:27 +0100]: [...] > > 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. Hello, I am a "passerby" with respect to this bug report, so to speak. I would like to ask a question: Martin, do I understand correctly that you are saying that recreating the QEMU/KVM testbed from scratch (with autopkgtest-build-qemu) is faster than upgrading an existing QEMU/KVM testbed? Despite the debootstrap step, which is notoriously slow?!? Johannes, have you found a solution in the meanwhile? P.S.: please bear with me: I am trying to figure out how to use autopkgtest with QEMU/KVM testbeds and I am probably still a bit too ignorant, but I failed to find some explanations in the documentation... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgptPRLwT5avo.pgp Description: PGP signature
Bug#886332: autopkgtest-virt-qemu: how to make persistent dist-upgrades
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
Bug#886332: autopkgtest-virt-qemu: how to make persistent dist-upgrades
Hi Martin, Quoting Martin Pitt (2018-01-04 16:19:07) > Johannes Schauer [2018-01-04 15:46 +0100]: > > 2. document which options to use so that the qemu image is persistently > > upgraded every time that sbuild runs autopkgtest > > The point of autopkgtest is to use ephemeral overlays, not to make anything > persistent. So this isn't and shouldn't be possible. > > > As for (1.), when I run: > > > > $ sudo qemu-system-x86_64 -enable-kvm -m 4G -drive > > format=raw,file=/srv/qemu/unstable-amd64-autopkgtest.img > > > > Then I get "no bootable device". > > Possibly because this is not a raw device, but a qcow2 image? There's little > reason to explicitly specify it, just let qemu figure it out by itself. Try > > -drive file=/srv/qemu/unstable-amd64-autopkgtest.img,if=virtio > > > As for (2.), I was unsuccessful to use the -U option or --setup-commands > > options to do persisting upgrades. This didn't work: > > Right, because autopkgtest-virt-qemu always creates an ephemeral overlay. It > never ever touches the given VM image. Thanks! The image indeed turned out to be a qcow image. I should've chosen a better extension to not get confused about this. ^^ Hrm... but I have some more thoughts and I see how they are out of scope of this bug and I should maybe open a new one (just tell me if you'd like me to). My central question: is it totally out of scope for autopkgtest to support modifying the underlying base image? 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. 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. So do you really see such a feature totally out of scope for autopkgtest? 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. Thanks! cheers, josch signature.asc Description: signature
Bug#886332: autopkgtest-virt-qemu: how to make persistent dist-upgrades
Hello Johannes, Johannes Schauer [2018-01-04 15:46 +0100]: > my use case is: use the autopkgtest qemu backend with sbuild. This works > well after having created the image with vmdebootstrap but after a while > the image has to be persistently upgraded. It would be nice if you could > either: > > 1. document how to easily upgrade a autopkgtest qemu image outside of > sbuild Note that autopkgtest does not require that the image you use with it was created by vmdebootstrap, and autopkgtest is not supposed to be a VM management tool. It merely can *use* a VM which satisfies certain properties (i. e. serial console or known root/sudo password). There's nothing magic about the vmdebootstrap images either - you can just boot them on the command line, or through libvirt, etc. That said, this can certainly be mentioned somehow in the autopkgtest-virt-qemu manpage. > 2. document which options to use so that the qemu image is persistently > upgraded every time that sbuild runs autopkgtest The point of autopkgtest is to use ephemeral overlays, not to make anything persistent. So this isn't and shouldn't be possible. > As for (1.), when I run: > > $ sudo qemu-system-x86_64 -enable-kvm -m 4G -drive > format=raw,file=/srv/qemu/unstable-amd64-autopkgtest.img > > Then I get "no bootable device". Possibly because this is not a raw device, but a qcow2 image? There's little reason to explicitly specify it, just let qemu figure it out by itself. Try -drive file=/srv/qemu/unstable-amd64-autopkgtest.img,if=virtio > As for (2.), I was unsuccessful to use the -U option or --setup-commands > options to do persisting upgrades. This didn't work: Right, because autopkgtest-virt-qemu always creates an ephemeral overlay. It never ever touches the given VM image. Martin
Bug#886332: autopkgtest-virt-qemu: how to make persistent dist-upgrades
Package: autopkgtest Version: 5.1 Severity: wishlist Hi, my use case is: use the autopkgtest qemu backend with sbuild. This works well after having created the image with vmdebootstrap but after a while the image has to be persistently upgraded. It would be nice if you could either: 1. document how to easily upgrade a autopkgtest qemu image outside of sbuild 2. document which options to use so that the qemu image is persistently upgraded every time that sbuild runs autopkgtest As for (1.), when I run: $ sudo qemu-system-x86_64 -enable-kvm -m 4G -drive format=raw,file=/srv/qemu/unstable-amd64-autopkgtest.img Then I get "no bootable device". As for (2.), I was unsuccessful to use the -U option or --setup-commands options to do persisting upgrades. This didn't work: --setup-commands 'mount -o remount,rw /' -U And neither did this: --setup-commands 'mount -o remount,rw /' --setup-commands 'apt-get update' --setup-commands 'DEBIAN_FRONTEND=noninteractive apt-get dist-upgrade -y' It would be great if the autopkgtest-virt-qemu man page could document how to upgrade the qemu backend. Thanks! cheers, josch
