proposal: Hybrid network stack for Trixie

[Lukas Märdian]

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

[Marco d'Itri]

Post by Lukas Märdian
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.

The problem with this argument is that neither systemd-networkd, nor
NetworkManager, nor ifupdown users are asking for a unified
configuration system, which also happens to be different from what they
are already used to.

Post by Lukas Märdian
It's sad to see that fellow DDs do not seem to care about consistency
and usability in this regard.

I think it's good that fellow DDs are wary of adding an indirection
layer which nobody asked for.

[Didier 'OdyX' Raboud]

Post by Lukas Märdian

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.

It sounds like having netplan be *available for install* solves that nicely if
one cares about consistency across their fleet of Debian hosts; just make sure
(via d-i preseed, cloud-init, etc) to install netplan when bootstrapping
machines/VM/hosts, and you're good to go, right?

I don't see any additional benefit by enforcing it on all installs by default,
as has been eloquently explained already.

[Daniel Baumann]

Post by Lukas Märdian
It's sad to see that fellow DDs do not seem to care

It's sad to see that in this and the other thread before, the same weak
arguments in favour of netplan are repeated by you without neither
adressing the valid points raised against it, nor providing an actual
counter argument to the discussion: for every point you're making to use
netplan, people pointed out better alternatives to actually do make
things better at the source.

Or in other words - my impression for netplan in one sentence is
"introducing an additional layer to paint over (valid) papercut-bugs
rather than fixing them properly in the original tools or documentation".

In Debian we stick to do the right thing, so, "thanks but no thanks" for
netplan.

Post by Lukas Märdian
about consistency and usability in this regard.

like consistency with any other linux distribution? wrt/ sd-networkd: in
the broader linux community we've pretty much standardized on systemd as
the init system. it just makes no sense to use sd-networkd with an
additional layer on top that nobody else is using. that's cross-distro
consistency and usability that we care for in the plumbing.

Regards,
Daniel