Bug#844459: autopkgtest: Please add autopkgtest-virt-uchroot

[Johannes Schauer]

Hi Martin,

Quoting Martin Pitt (2016-12-08 16:37:58)
> Johannes Schauer [2016-11-26  6:03 +0000]:
> > I don't know what the best course of action here is. Should sbuild expect that
> > after the user presses Ctrl+C, the autopkgtest backend takes care to completely
> > shut down the backend by itself? I don't think this is a viable option because
> > the autopkgtest backend used by sbuild might be one that carries over changes
> > made by sbuild to the next session. And in that cases, the session must not
> > just close under sbuild's feet but sbuild must be given the chance to clean up
> > after itself after the user cancelled the build with Ctrl+C.
> 
> Thanks for figuring that out. Indeed the trouble stems from the fact
> that there are two different entities trying to control/own the
> schroot session -- sbuild and autopkgtest.
> 
> I don't think that autopkgtest's schroot runner is at all appropriate
> for this -- sbuild already creates the chroot and wants to clean it
> up, and autopkgtest shouldn't -- autopkgtest should also not revert
> the testbed (in case the test requests it). My recommendation is to
> use the chroot runner for that, which doesn't have the "revert"
> capability and thus neither the SIGINT nor the "accidental revert" can
> happen.
> 
> Of course the chroot runner cannot run a lot of tests, but this would already
> be true with this approach anyway.

maybe we are talking past each other here.

Are you saying that this incompatibility affects all autopkgtest backends that
offer the "revert" capability? That would mean that the problem is not limited
to the schroot backend. It would mean that the sbuild autopkgtest backend
cannot be used reliably (that is - also support the user sending a SIGINT to
the sbuild process group) with any backend that offers "revert". That would for
example include the very useful qemu or lxc backends.

I do not understand your argument why you do not find autopkgtest's schroot
runner appropriate for this. Can you elaborate? Sbuild doesn't create the
chroot at all.

Why would using the chroot backend be any use here? That would be a step
backward because I want to go away from trivial backends and instead leverage
autopkgtest to let builds run in complex backends like schroot, qemu, lxc or
even over ssh.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20161208/96654abd/attachment.sig>