| Huh, nifty, sort of. But I think this whole model is wrong. For as long as I'm aware, every serious network config system (at least Cisco IOS and everything that came after) has it right: there is a live configuration and a saved configuration. You can edit the live configuration, and you can commit to the saved configuration. So with netplan try, you edit the configuration, hope you don't crash or otherwise reboot, run netplan try, and hope it succeeds in rolling back on failure. That's a lot of hoping. With old IOS, you would just not do 'write memory' until you get the configuration right. Similarly, netplan apply -state relies on the user to do some horrible manual shuffling of configuration. An IOS-like solution would make this automatic. In the context of netplan, this could be quite straightforward. Instead of just /etc/netplan, there would be: /etc/netplan: The configuration to be loaded at boot. /var/run/netplan-live: The configuration that was most recently applied. NOTHING EXCEPT THE NETPLAN TOOLING EDITS THIS. /tmp/whatever (or any other path): configuration that the administrator wants to test. To use it, the admin could stage their configuration anywhere they want and netplan apply it. Then netplan commit would commit the running configuration to /etc/netplan. -state is automatic: it's in /var/run/netplan-live. re: the last issue, one of my servers has a NIC with a name like eno12345np1. On that physical link is a vlan with tag 1234. This gives a name like "eno12345np1.1234". That plus the trailing NULL is 17 bytes, which is too long. Now this isn't strictly netplan's fault (although eno12345np1 really is excessive IMO), but the fact that netplan can't intelligently handle this or at least notice when I do netplan apply is fairly sad. |