Hi, Thank you for considering netplan as the distro default in Debian!I am the upstream netplan maintainer (and downstream maintainer of the netplan.io package in Ubuntu) and would be happy to help with implementing this switch to netplan. Also, I do have a few thoughts to share wrt. this discussion.
Are you saying "everything breaks" as in: A) the change is not applied (correctly) in the way that it would be if the system was rebooted, or B) the change is applied, but the human made a mistake in the config and the change breaks things, or C) B + the human gets cut off from e.g. SSH due to the error? I would say (generally) that A is a bug, B is inherent to any toolingapplying a human's instructions, and C can be addressed by a rollback function.`netplan try` covers C (and thus also B). `netplan apply` (and thus `netplan try`) have a caveat that they don't remove virtual devices that are no longer described in the config. This feels like an example of A, though it's arguable how much it matters.
B & C: ACKRegarding A: We have just recently landed a change in upstream netplan that allows to mitigate this exact problem, by passing the previous state. netplan can then calculate the delta of virtual interfaces and cleanup after itself (in some cases this can and is done automatically):
https://github.com/canonical/netplan/pull/231
I am saying: remove the IP address from an interface, move it to a VLAN instead. You'll get a duplicate IP.
This sounds like another bug, that should be addressable in a similar way to the fix mentioned above.
ifupdown2 is smart and will converge to the new configuration. Network Manager can restart and minimize impact. AFAIK, systemd-networkd is as dumb as ifupdown and does not know how to converge.What does converge mean in this context? Is something needing to apply parts of the changes iteratively to arrive at the desired state?It makes a diff between the current system state and the desired state and applies actions to move to this state. The current system state could be from a previous application of the tool or from manual action from the operator, it does not matter (this is a second advantage of such a tool). The above situation is handled perfectly.My point is that ifupdown2 was a possible successor to ifupdown but was never adopted because written in Python. As netplan is written in Python, ifupdown2 seems a far better replacement.Am I understanding correctly that ifupdown2 is an alternative tosystemd-networkd and NetworkManager (as opposed to netplan, which is a layer on top of them)?Yes.
Well.. netplan is not actually written in Python. But is primarily implemented in C, consisting of the libnetplan library that contains all the parsing and YAML progressing logic and a small "generate" binary that is usually executed during bootup as a systemd-generator [0] to prepare any systemd-networkd / NetworkManager / OVS / SR-IOV configuration that might be needed.
Only the interactive and user facing CLI is implemented in Python, calling into libnetplan and executing the 'generate' binary if need be.
I'm not a Debian Developer, so it's not my call, but still I'd like to provide a few more points as to why netplan should be the distro default in Debian:
* Netplan is under active development, providing several new releases per year and supported by Canonical.
* Licensed under GPL v3.0 without any CLA. * Implemented as an efficient C binary (systemd-generator)* It provides a single place for network configurations in /etc/netplan, independently of it being used on a server (systemd-networkd) or desktop/wifi setup (NetworkManager). This increases usability as the documentation does not need to differentiate too much between different scenarios.
* Reducing the delta to Ubuntu and making use of the big knowledge base that grew since 2018 when Ubuntu switched to netplan by default (e.g. https://askubuntu.com/questions/tagged/netplan?tab=Frequent). Many scenarios have already been discussed in this time and solutions have been found.
* Smaller configuration files (in comparison to (networkd/NM), that can be split up into multiple files if wanted or needed, can be overwritten by the user or admin (via /{lib,etc,run}/netplan overrides) and other packages can ship drop-in snippets that provide a certain piece of network configuration on installation.
Cheers, Lukas [0] https://www.freedesktop.org/software/systemd/man/systemd.generator.html