Comment 20 for bug 1804861

MAAS picks up information at commissioning time about the system. This would include the NIC driver, which could just as well be used as an additional matching criterion in netplan YAML.

There's a limit to how much netplan can and should try to figure out what one means: we're supposed to do *translation* of configuration -- sure, we could check the running system at the time to try to make the config more precise, but that only helps *iff* the user wasn't actually precisely requesting what they wanted. Anything we add to what's written in the actual netplan YAML needs to be carefully weighed against whether we risk actively going against what the user has written. The user knows best what their network is like.

This is why I'm strongly suggesting that in addition to what I'm adding in netplan, changes are made to MAAS to ensure the config is as precise as it possibly could be, while also not including default values on optional fields without the admin making a conscious decision on adding these values (ie. default MAC for a bond). MAAS knows what the MAC for a physical device is, what its name should be, and even down to the driver. Sure, any of those could change, but that's not different from any other environment: devices fail, hardware needs replacement. The MAC would have changed anyway. At least with MAAS you can re-commission and re-deploy systems easily when that happens.

I've added https://github.com/CanonicalLtd/netplan/commit/a27122bc8d8e066b1a90a7fd8d65342e8b906a8e to netplan work mitigate the current issue. This shouldn't be considered an end-all solution -- I still think other pieces of the network stack need changing.

It's as much as I am comfortable adding to netplan to mitigate the problem. There isn't enough information coming from the YAML to figure out more details about the interface, nor a non-hackish way to retrieve the information from the system when networkd will do the matching later.