Re: proposal: Hybrid network stack for Trixie
On 22.09.24 12:22, Chris Hofstaedtler wrote:
* Lukas Märdian <slyon@debian.org> [240920 13:13]:
I've repeated the reasons why I think a hybrid stack using Netplan is a
feasible solution many times in previous threads, therefore I'd like to refer
to a list of frequently asked questions, instead of spreading more reasons
across more replies: https://wiki.debian.org/Netplan/FAQ
# Why
The ifupdown package is a Debian only solution that is becoming a maintenance
burden. We've had plenty of discussions over the years and consensus is that we
want to get rid of it.
Some variations of Debian have already moved forward with choosing a different
stack, such as desktop/laptop installations (using NetworkManager) and cloud
images (using Netplan+systemd-networkd). Also, ifupdown-ng exists as a modern
re-implementation of the classic tooling, that strives to become drop-in
[compatible].
Thanks for providing the FAQ and this "Why" section, but it seems to
leave open why we would want or need netplan as the default. As the
FAQ shows, netplan is available as an optional package in many
distros. The same is already true in Debian thanks to you.
As described in the "Proposal" section and first answer of the FAQ, it's all
about consistency.
There seems to be a tendency for moving towards a hybrid stack, using
sd-networkd and NetworkManager in different contexts/use-cases. But having
fragmented ways of doing network configuration provides bad UX, as it can
confuse users, who first need to understand what sortf of Debian they are
using, before looking for solutions.
Netplan solves this and allows for providing common solution that work
across the system.
The Netplan tooling around that, like "netplan status" or "netplan try"
to query/debug the network configuration or apply, but roll-back
configuration, in case it did not work out as expected, are only added
benefits.
For your described usecase groups, which seem to clearly map to the
backends used by netplan, I do not see what netplan brings to the
table. The "server" group supposedly wants (and I agree) networkd,
but they also want the configuration interface of networkd.
The "laptop" group supposedly wants (and I agree) NetworkManager,
but they also want the configuration interface of NetworkManager.
Who actually wants the configuration interface of netplan,
especially by default?
I see nobody saying "yet another layer is a lot of fun!", and the
usecase groups do not overlap that much, that they both would *need*
the same interface? The opposite seems to apply.
It's sad to see that fellow DDs do not seem to care about consistency
and usability in this regard.
PS: I know this proposal doesn't please everybody, but I think it's the most
actionable option that we have on the table and strikes a good compromise. As a
replacement for ifupdown is overdue, we should adopt our network stack for
Trixie.
d-i could make (or offer) a choice between networkd and
NetworkManager. Doesn't have to be netplan. I can vaguely see how
d-i might be simpler by writing netplan config, but it still has to
make a choice of the default backend? And then what does netplan
help here?
Given d-i then will have to make a choice, *none* of the networking
stack packages should have a "Priority:" higher than optional. As
in, even if we would go with netplan in d-i, there is no "default"
anymore and people have to make choices.
As stated below, d-i already makes this choice between ifupdown,
NetworkManager and Netplan, depending on context of installed packages
in the target system. There's also a (stale?) MR to add systemd-networkd
to the mix [1].
Personally, I do not necesarily think showing more options to the users
is better. But I've heard this being suggested several times. So how
do others think about having a network-stack selection in
debian-installer/tasksel? Similar to the desktop-stack selection.
Cheers,
Lukas
[1] https://salsa.debian.org/installer-team/netcfg/-/merge_requests/11
Reply to: