Hi all,
Recently, I was working on a project that led me to become frustrated with the current state of `systemd` and `ifupdown` (e.g. /etc/network/interfaces or /e/n/i) in Xenial. I remembered that `netplan`[1] was under development, so I added the PPA for Xenial and gave it a try. Unfortunately, it didn't solve the issue for me[2]... but I also realized there was a blocking issue in the way of my adoption of it.
Let me explain my use case: when an interface goes up or down, I want to be able to do event-driven things with the network configuration, such as add or remove routes, run a DHCP client, etc. My first attempt to make this happen was to add `post-up` and `pre-down` scripts to do this. However, this had a fatal flaw for my application: `ifupdown` doesn't separate the concept of operational status from the concept of administrative status. (That is, in `ifupdown`, an interface is "up" if the admin says it is up. Link up or link down does not seem to matter; it's strictly an /administrative/ status[3].)
Long story short: in order to get the behavior I wanted, I wrote a custom script that monitors *operational status* (aka physical link up/down status), and I launch it using /e/n/i's `post-up`, and bring it down using /e/n/i's `pre-down` scripts.
Looking at the `netplan` spec[4], I don't see a way to achieve that functionality. I know that many people are using the script-callout functionality in /e/n/i to achieve what they need to achieve, so it seems to me that having this in `netplan` is critical to achieving parity with what we have in Xenial with `ifupdown`.
In an ideal world, I think `netplan` would be able to model my use case out-of-the-box.[5] But since we can't expect to model everyone's use case, it seems like custom scripting functionality is a hard requirement, though perhaps one that could have tricky cross-platform implications.
Thoughts?
Regards,
Mike
[2]: The behavior was exactly the same, which is actually good for consistency.
[3]: Well, it is after an annoying 5 minute timeout, in some cases.
[5]: As an aside, this brings up an interesting subtle difference between rendering a networking configuration with (networkd, ifupdown) vs NetworkManager. In NetworkManager, there *IS* a concept of operational status, and I would have been able to get closer to the behavior I wanted, if I was willing to pull in all those dependencies. We should be mindful that rendering the same configuration on NetworkManager, even for simple things like a static IP address and a DHCP interface, could produce drastically different behavior than with networkd or ifupdown.
