Hi,
On 9/22/24 19:22, Chris Hofstaedtler wrote:
The "server" group supposedly wants (and I agree) networkd, but they also want
the configuration interface of networkd.
I'm not sure about that -- I'd expect the "server" group to be split into
- "pets": their IP address doesn't change often anyway, anything
beyond "set IP address during boot" is bloat. ifupdown is bloat because
it requires a python interpreter to do what a one-line shell script can
do, and networkd is bloat because it runs an entire service to do nothing.
Nobody cares about either kind of bloat, because resources are cheap --
what people do care about is interface stability, which is why switching
the interface naming scheme was so controversial back then.
- "cattle": the IP configuration comes from a central place, and is
integrated with asset management. If it's a small operation, they use
DHCP, but anything more sophisticated brings their own management
solution, and whatever system we provide needs to be able to go out of
the way.
- "container": the IP address is managed from outside. The OS
installation we generate should not interfere.
The "laptop" group supposedly wants (and I agree) NetworkManager,
but they also want the configuration interface of NetworkManager.
They specifically want the user interface. The configuration interface
is less of a contract and more of a guideline, but that doesn't matter
to the users, because they will only ever use the integrated solution
where system and UI components are provided by the same package, and are
kept consistent that way.
Providing a typesafe interface for passing the privilege-separation
boundary is hard, but it is much more difficult if that interface also
needs to be long-term stable. Anything that wants to replace N-M is
either a rewrite with the same basic structure (tightly coupled
interfaces on both sides of the privilege separation boundary, upgraded
in lock step) or a massive sink of manpower that, frankly, no one has.
Who actually wants the configuration interface of netplan,
especially by default?
I can see it in the server space, because we need the integration with
other tools that contribute fragments of network configuration without
wanting to take over (libvirt and docker), and with tools that take over.
Integrating these tools into a consistent whole would be the core task
of a distribution.
ifupdown defines a policy that works reasonably well on servers: "do not
interfere." That is, if libvirt or docker change something because they
need it (like moving the default route into a bridge), then ifupdown
does not revert that change. It's shit, but it works.
systemd-networkd, for good reasons, deviates from this, but this means
further integration work is required from the distribution because the
end result needs to be consistent again. If netplan can provide the
"consistent whole", then it makes sense not to reinvent the wheel.
My expectation as a user is that I should be able to install libvirt and
docker on a server, and configure bridged networking in both without
losing connectivity.
Right now, it works by accident, which is bad, but breaking it in the
name of correctness will make a lot of people very angry, like renaming
all the interfaces or requiring "nofail" in the fstab to continue
booting did.
Simon
