No network devices configured if YAML error in any file

[Daniel Axtens]

- Start a VM with a network interface created by cloud-init (say ens3), and assume you have no physical console (e.g. cloud VM)
- Add another network interface (say ens7)
- Create another YAML file to configure ens7, but make a small error. This file need not reference ens3 at all!
- Reboot machine

- Observe the following message on boot
systemd[332]: /lib/systemd/systemd-generators/netplan failed with error code 1.

- Observe that you can no longer SSH in to the machine because the error in the new yaml file prevents all generation, so ens3 is not configured.

This is observed with the latest code on git. It renders the system entirely unusable unless there is an alternative way to get in.

 1) An error in the configuration of device X should not stop device Y from being configured!
 2) Users should be instructed to always run netplan-generate to test for bugs. (Maybe a wrapper like visudo or crontab -e would be good?)

[Simon Chopin (schopin)]

Hello,

After a discussion with the current Netplan team, we've reached the conclusion that we prefer the current behaviour of failing completely rather than applying a partial configuration. Our decision is based on several factors:

* The predictability of the system is greater: either it produces a full backend configuration, or none at all
* Partial application might actually break systems when applied directly via netplan apply. For instance, if the operator's SSH connection is routed through a bridge, and said bridge configuration is faulty, netplan apply will break the system, whereas an overall failure would leave the current configuration untouched.
* Operators are expected to test their configurations using netplan try and netplan apply, which should at least catch syntax issues before the reboot scenario.

Consequently, I'm marking this bug as WONTFIX.