On Sun, 14 Jul 2024 at 17:09:48 +0100, Steve McIntyre wrote:
> Luca Boccassi wrote:
> >Networking is not static, it constantly changes in the kernel,
> >sometimes in dramatic and incompatible ways.
>
> Sorry, but no. Networking clearly is *not* changing that fast, in
> software terms. Many old tools still continue to work just fine after
> a decade or more.
Yes, I think I agree with Luca's conclusion, but not so much with this
argument: the parts of networking that are relevant for a default choice
that lets users get started (approximately the subset supported by d-i)
don't move that fast.
> 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.
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.)
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.
The design of python3-dbus (dbus-python upstream) involves a lot of
type-guessing heuristics, which pre-date my involvement in it, and cannot
be fixed without significant compatibility breaks. I do not plan to make
those compatibility breaks, because if a project is willing and able
to migrate to a hypothetical incompatible dbus-python 2.x, it might as
well migrate to a different D-Bus library with a different name instead
(which it could do any time, without waiting for me).
When I accepted maintainer status on python3-dbus, I was *not* prepared
for it to be part of the base system: if a bug in python3-dbus turns
out to be critical to system function when using Netplan, I am not going
to be able to drop everything and fix it. That library is way, way down
my list of priorities, especially now. I'm sorry, but I am not willing
to be the random person in Nebraska[2] for this particular library as
a dependency of our default server/embedded installation.
(I realise that this is not consistent with what the community demands,
because the open-source community expects every maintainer to treat
every component they maintain as their top priority at all times, and we
collectively have enough cognitive dissonance to continue to expect this -
but when I put it like that, I hope it's obvious that this expectation is
nonsense. I'm sorry, I only have a limited amount of time and brainpower,
and every time I put security-sensitive packages like GLib and Flatpak
higher up my priority list, that necessarily pushes something else lower
down my list.)
I am not involved in libyaml, python3-yaml and other dependencies enough
to comment on whether they raise similar concerns.
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).
smcv
[1] as in: "python3-dbus is unmaintained, and I am the unmaintainer"
[2] https://xkcd.com/2347/
