Hi Helmut, 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.
On 2024-12-20 13:58, Helmut Grohne wrote: > Once upgrading autopkgtest, I had my incus container image creation fail > in setup-testbed. Ultimately, the setup-testbed script would fail at > > printf 'auto %s\niface %s inet dhcp\n' "$iface" "$iface" >> > "$root/etc/network/interfaces.d/$iface" > > As the interfaces.d directory would not exist. (Don't ask me why, it > existed in the image.) That lead me into a deep rabbit hole of setting > up container networking and I think what autopkgtest does here is not > quite up to the task (but my base image was neither). > > My base image happened to be a default variant and thus included the > important package ifupdown. Thus netconf_exists would go into the > ifupdown branch and conclude that I have no networking configured. I > question whether this approach is useful. ifupdown can easily end up > being installed without causing harm otherwise. In this case, networking > was set up using networkd, but netconf_exists would not recognize that > as it was assuming that ifupdown was in use. I ended up removing > ifupdown to get past this step. I think this is a first bug: the ifupdown branch [3] is nested and the ifupdown config existence checks happen in the sub-branches. 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. > 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. > 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? > I argue that the check is not doing the right thing for > the most common way to set up container networking. The file will exist > for any systemd installation so in principle, we should replace the > check with "if networkd is enabled", but that happens to also be the > case for netplan.io and then we'd always skip configuring netplan.io. 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. 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. > That seems bad as well, so the question arises: How do we properly tell > setup-testbed that host0 networking with networkd should be used? 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. Or, if images are built where networkd is enabled by default, to prevent later installation of ifupdown. Best, Christian [1]: https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/322 [2]: https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/322#note_481795 [3]: https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/setup-commands/setup-testbed?ref_type=heads#L360
