On 2025-01-02 08:08, Helmut Grohne wrote:
>> Again, not one of the maintainers, but at least in the context of the
>> MR, the idea was to do something useful when a default install is
>> detected, one via autopkgtest-build-* for example.
>
> I'm not sure there is that much of a universal default in reality.
True. With "default", I primarily had in mind what autopkgtest-build-*
produce, as the testbeds they produce should be as close as possible to
what is "typical" I guess, to have high test fidelity.
By implication, that means what debootstrap produces, whether it's used
directly by autopkgtest-build-qemu, or indirectly by
autopkgtest-build-podman (which actually uses debuerrotype, but same
principle).
Not that autopkgtest-build-qemu uses the default --variant, whereas the
container images are built with --variant=minbase. This means that these
testbeds should, by default, be configured exactly as you expect, namely
* QEMU: ifupdown for Debian and Ubuntu <= bionic
* QEMU: netplan for Ubuntu > bionic
* container: no config
(However in my MR, I only tested the QEMU modes)
> There is a strong difference between virtual machines and
> containers. Most
> container runtimes will now name the primary network interface host0
> triggering automatic configuration by networkd whereas host0 is not
> typically preset in virtual machines. I argue that setup-testbed should
> follow this distinction (not sure how though). If it is preparing an
> image for a container runtime and sytemd-networkd is enabled, it should
> consider that sufficient configuration. Otherwise, what it does is good.
>
> Unfortunately, figuring out whether a container is being prepared is not
> entirely trivial. For instance, the images produced by debvm-create can
> be booted as containers or virtual machines.
Ah, and herein lies the difference to the above, where our assumption
becomes an issue.
>[...]
> I argue that setup-testbed has no chance of correctly detecting the
> various scenarios desired
Yep, this was the assumption behind the original MR as well.
> and suggest that it should provide
> configurability as to whether a network should be configured. How about
> adding another environment variable? There already are e.g.
> AUTOPKGTEST_KEEP_APT_SOURCES and others. How about
> AUTOPKGTEST_NETWORK_INTERFACE? This is currently guessed as eth0 unless
> detectable from inside (when root=/). I'd add the logic
>
> if $AUTOPKGTEST_NETWORK_INTERFACE = host0 && systemctl is-enabled
> systemd-networkd; then
> return 0 # assume network to be configured
> fi
>
> Thus any user of setup-testbed could now opt out of its network
> configuration by setting AUTOPKGTEST_NETWORK_INTERFACE=host0. Then, all
> of autopkgtest-build-{docker,lxc,lxc,incus,podman} could set this
> variable in precisely that way thus opting out of setup-testbed's
> network configuration.
I think adding a way to suppress the default configuration through some
envvar is a great idea. Most importantly, it can be documented in the
respective man pages, so it is discoverable without having to dive into
the code. This would help anyone supplying their own custom image.
If this is a pure opt-out, I'd probably name it
AUTOPKGTEST_NETWORK_SKIPCONFIG=1 or something, as _INTERFACE=host0 might
be misinterpreted as having more logic attached to the interface name
("prefer this interface", "rename the primary interface to this", ...)
But again, not a maintainer, so just thinking out loud.
Best,
Christian
