Re: proposal: Hybrid network stack for Trixie

[Lukas Märdian <slyon@debian.org>]

On 23.09.24 13:33, Richard Lewis wrote:
> Lukas Märdian <slyon@debian.org> writes:
> > On 23.09.24 12:27, Ansgar 🙀 wrote:
> > > On Mon, 2024-09-23 at 12:22 +0200, Lukas Märdian wrote:
> > > > On 22.09.24 15:58, Ansgar 🙀 wrote:
> > > > > On Fri, 2024-09-20 at 13:12 +0200, Lukas Märdian wrote:
>
> > > > The benefit that Netplan would provide in such cases is that
> > > > debian-installer
> > > > installs a /etc/netplan/01-network-manager-all.yaml config file, reading:
> > > >
> > > > network:
> > > >      version: 2
> > > >      renderer: NetworkManager
> > > So on desktop installations including NetworkManager, netplan will
> > > be
> > > configured to do nothing? Why install netplan at all on desktop systems
> > > then?
> >
> > Because it allows to add configuration in a way that is common with
> > server, cloud
> > and other instances of Debian
>
>
> Could you give an example of why this is useful to unify?
>
> For example: is there a scenario in which someone is using
> systemd-networkd but then finds they need to do X, which they cant
> essily do using systend but which nm support is better--- therefore if
> they are using netplan they can simply install network-manager, change a
> netplan setting and gain X with no need to understand the differences
> between the network-manager and systemd configuration languages?

My ideas was not so much about switching from one networking daemon to another.
In most cases users will probably stick to the network stack of their chosen
environment. With systemd-networkd and NetworkManager being good candidates for
their corresponding scenarios.

But knowledge builds up over the years in our community and spreads around forums,
stack overflow, etc.

Those are the places where we figure out "How to setup a bond on Debian?",
"How to connect a headless embedded board to the WiFi network" or "How to change
the embedded-switch mode on SR-IOV physical functions?". We find solutions and
help each other out, which is great!

But with fragmented network-configuration tooling those solutions will not work
in many cases, as they depend on a specific context of the base-image in use
(e.g. server vs desktop vs embedded vs cloud).

With Netplan I'm hoping to avoid such frustration by providing a way to configure
the network that works independently of the base-image context. Of course without
forcing people to use it or impacting the lower layer to be configured directly.

-- Lukas