Hi Christian,
On Wed, Jan 01, 2025 at 12:24:14PM +0100, Christian Kastner wrote:
> not one of the maintainers, but for context, the current configuration
> was discussed in [1]. See this thread [2] for how the logic when
> something is to be configured or left alone evolved.
Thank you for the feedback.
> However, if ifupdown is detected but no config is found in these
> sub-branches, then there is no way the netplan and networkd branches can
> get visited.
>
> I think these (outer) branches shouldn't be if/elif/elif, just if/if/if.
> The former was chosen under the assumption of short-circuiting, for
> which we now have a counter-example.
I agree with your conclusion in principle. However, that change will not
fully address the host0 use case, because the short-circuited networkd
test still does not recognize a configured host0 network (and it really
cannot).
> > The next item is the real problem in my view. netconf_exists then checks
> > for /etc/systemd/network/*.network to see whether networkd is properly
> > configured. In many recent container and virtual machine deployments,
> > the network is configured in
> > /usr/lib/systemd/network/80-container-host0.network.
>
> IIRC in the MR, we just adapted the existing code for systemd which just
> checked in /etc, so the /usr path was just an oversight, not a conscious
> decision.
I don't think this is an oversight. If net networkd code were
considering /usr/lib/systemd/network/80-container-host0.network as a
valid network configuration, any image that has the systemd package
installed would be recognized as having a configured network. Since
netplan.io depends on systemd, the result would be that netplan.io would
never be configured. I very much doubt that this was desired.
> > That happened to be the case for me, but this file does not match /
> > etc/systemd/networkd/*.network of course, so then netconf_exists
> > concludes that this is not configured using systemd-networkd even
> > though it actually is.
>
> And thus configure_network attempted to configure ifupdown, and this led
> to the interfaces.d failure you mentioned above, right?
Confirmed. I have not spent effort into figuring out why configuring
ifupdown fails precisely as using ifupdown was not the goal in my
context.
> 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. 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.
In reality, it actually gets worse. The responsibility for network
configuration is not well-defined. There are multiple stakeholders that
compete here:
* The base image can already be set up with proper network
configuration.
+ systemd-networkd does this for containers that name their interface
exactly "host0".
+ Some base images just bring up any network interface using dhcp.
For example a .network file with [Match]Name=en* eth* and
[Network]DHCP=yes is usually sufficient.
- debvm-create does this.
* The image customization step can set up network configuration.
+ autopkgtest's setup-testbed assumes this role
* The runtime may configure networking.
+ Both pasta/passt and slirp4netns default to bringing up network
interfaces fully configured. What is missing is a suitable
/etc/resolv.conf though.
I argue that setup-testbed has no chance of correctly detecting the
various scenarios desired 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.
> Because in the non-default case, the user must have explicitly installed
> some other configuration tool. In which case it would not unreasonable
> to assume that the user also configured this tool. Conversely, the
> ambiguity introduced by the presence of multiple tools makes reasonable
> assumptions about the Right Thing much more difficult, as you point out.
Exactly.
> Given the above, if networkd is to be used, then the simplest solution
> would be to purge ifupdown as a second step to enabling networkd.
I did some more testing and figured another detail. If you install
systemd, systemd-networkd is default disabled. If you want to use its
automatic host0 configuration, it must be enabled by some means. If you
install netplan.io, systemd-networkd still is disabled. If you configure
a network interface using netplan.io using the networkd renderer, it now
becomes "enabled-runtime" which is not the same as "enabled". So it may
actually be possible to tell these apart. We may consider
systemd-networkd as configured if test "$(systemctl --root "$root"
is-enabled systemd-networkd)" = enabled and this test will likely not
flag a typical netplan.io installation.
More feedback on these thoughts welcome.
Helmut
