On 14.07.24 20:20, Simon McVittie wrote:
On Sun, 14 Jul 2024 at 17:09:48 +0100, Steve McIntyre wrote:
Luca Boccassi wrote:
[...]
I understand what you're trying to say, but that's a disingenuous
comparison. systemd is a massive (some would say *too* massive)
project with fingers in many pies. How many of those people have
touched *networking* bits?
This is also a valid point, although there are really two contributor sets
that matter: the contributors who have actually touched networkd, and the
more general systemd contributors/maintainers who don't routinely touch
networkd but would step up if necessary to handle serious issues in it,
having taken responsibility for it as part of the wider systemd project.
I assume that second set is considerably smaller than systemd's whole
contributor list, but still significant in size.
As other stated, I think the systemd vs Netplan contributors stats are skewed.
It's not an apples to apples comparison. Doing some back of the napkin maths
("cloc" commands), the systemd codebase is roughly 20x bigger in terms of LoC,
compared to Netplan. – Which is totally fine, as it handles much more stuff.
I don't want people to think too much in terms of "sd-networkd VS Netplan",
but rather in terms of "sd-networkd PLUS Netplan". Contributors to Netplan
naturally build up knowledge in sd-networkd (and NetworkManager), so we would
actually have more minds knowledgeable about our network stack.
Furthermore, we would get all the CI, tooling and tests around
systemd(-networkd),
in addition to all the CI, tooling and tests around Netplan. Just recently this
combination of testing spotted an issue with link-offloading (ethtool) settings,
which would otherwise have slipped through the cracks.
It's now being worked around in Netplan, while an upstream systemd bug was
filed:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071220
https://github.com/systemd/systemd/issues/33619
I think perhaps more convincing arguments to be made in favour of
preferring to use networkd directly as a default, rather than netplan, are:
Number of components we rely on
-------------------------------
If we use networkd directly, then our default server/embedded installation
can be broken by a bug in either d-i or networkd. If we use networkd via
Netplan, then our default server/embedded installation can still be broken
by a bug in d-i or networkd, but it can also be broken by a bug in netplan.
That's more "accident surface" (like attack surface, but with no actual
attacker, since all of this is trusted system-configuration stuff that
hopefully only the sysadmin can manipulate).
This is not a criticism of the quality of Netplan, so much as a criticism
of adding an abstraction layer over something that we could equally well
use directly: a design with an abstraction layer over a backend is
still vulnerable to the backend's bugs, so the abstraction layer can only
reduce overall robustness (in the best case, where the abstraction layer
is literally perfect, all it can do is match the level of robustness of
the backend).
To illustrate that point, suppose that abstraction layer A (which
works 99% of the time) uses backend B (which works 90% of the time).
If we combine the two, we can only expect the result to be
(.9*.99) ~= 89% reliable - that's worse than either A or B.
Obviously I hope that both Netplan and networkd are much better than those
arbitrary numbers that I made up just now, but neither one is perfect.
Replace server/embedded with laptop/desktop and networkd with NM, and the
same idea applies. (Indeed, the same would still be true when comparing
our current direct use of ifupdown with Netplan + ifupdown.)
This is a fair point and applies to every component that we ship as part of
the default installation. Therefore, we need to carefully consider pros and
cons of each component, as we're doing right here :)
In the case of sd-networkd + Netplan it can also be flipped on its head,
considereing we'll overall have more testing and more contributors
knowledgeable about networking, when accepting both tools as part of the
stack (see section above).
Dependency size and maintenance
-------------------------------
I also notice that the netplan.io package would bring GLib, Python,
python3-dbus and python3-yaml into the dependencies of the base system,
among others. As an upstream and downstream maintainer of GLib, and in
practice the only upstream and downstream unmaintainer[1] of python3-dbus,
I'm not comfortable with that, both for size reasons (GLib and Python
are not small) and for quality and maintainedness reasons (python3-dbus).
GLib and Python are relatively large in both on-disk size and attack
surface, but they're essential to our desktop installations anyway,
reinventing them in parallel would be worse than reusing them, and
their maintainers have already accepted the responsibility of them
being an important system component. So those two are actually not my
main concern here, and if we had no good alternative, I'd be saying:
yes they're relatively bulky for a container/embedded use-case, but on
a typical server installation they're fine.
python3-dbus is a concern to me, though.
[...]
I am not involved in libyaml, python3-yaml and other dependencies enough
to comment on whether they raise similar concerns.
I dropped some of the python3-* concerns from the citation, as I think it's
not relevant (anymore). We've had a similar networking discussion last year
where Netplan's Python dependency was brought up as a concern. That's why we
split out the "netplan-generator" package. The Python dependency is only
needed for Netplan's CLI that brings convenience features and can be installed
optionally.
For the default installation, we're only talking about "netplan-generator" +
"libnetplan1", which does have transitive dependencies on GLib (yes), libuuid
and libyaml, besides libc. So the footprint is fairly small.
Benefits vs. costs
------------------
I can see that Netplan aims to have some benefits over configuring the
backend directly: its configuration format might be nicer than networkd's
or NM's (this is a matter of opinion, I personally think networkd syntax
is fine in at least the simple cases that are relevant for a default),
and it lets a sysadmin switch between backends without explicitly
translating configuration (I'm not convinced this actually happens
frequently enough to justify the complexity, but opinions can vary).
The question for the project is whether those benefits, in total, exceed
the costs of adding this layer over the top of what we could just be
using directly (networkd or NM, or for that matter, ifupdown).
I think you're lacking a very important point here. As a project we want to
have a congruent answer following question:
= "How to do networking on Debian?" =
If we have to tell our users and sysadmins to do "X" on Debian server systems
(using ifupdown or potentially sd-networkd), while doing "Y" on Debian desktop
systems (using NetworkManager), while doing "Z" on Debian cloud systems (using
Netplan), while doing something totally different on RaspberryPi (or alike)
boards
that run a Debian server setup, but using WiFi as their primary network
interface,
that's just a really bad user experience.
Using Debian should NOT feel like using different distros. And we really need a
common way to do network configuration. With Netplan we can tell people to just
use
use the "dhcp4: true" setting (for example), which will work on all Debian
systems
and is automatically translated to the corresponding backend for
server/desktop/cloud/embedded usecases.
All while giving sysadmins the flexibilty to fully utilize the underlying
network
daemon directly, if they feel like writing native configuration for it (or don't
like Netplan).
Cheers,
Lukas
