Hi, On Tue, 2024-09-24 at 15:34 +0200, Lukas Märdian wrote: > 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.
But this only works for features for which all the following is true: 1. The feature is supported by systemd-networkd, 2. The feature is also supported by NetworkManager, 3. The feature is also supported by netplan. Any feature not supported by all three will lead to fragmentation: one would first have to make sure to switch to, for example, the NetworkManager backend, but then might just find out that netplan doesn't support the feature and one has to configure NetworkManager without netplan anyway. At that point just making NM the default without additional layers might be better: the feature set covered by just - The feature is supported by NetworkManager is larger than the earlier feature set. Ansgar
