Comment 17 for bug 1804861

This is a long thread; sorry for adding fuel to the fire. But I have a some questions/comments.

(1) I feel like if we don't fix how matching works for 'ethernets' in Netplan, we're not mapping the user's intent to an appropriate configuration. The user is saying "I have two physical interfaces. I want the one that has MAC X to have name A. I want the one that has MAC Y to have name B." They aren't modeling anything about what they want the bond configuration to be. They're telling Netplan how to identify a particular interface.

That is, users won't be thinking in terms of the resulting match rules. They're thinking in terms of how we've presented the model in Netplan.) If Netplan determines that the configuration would be ambiguous, it's free to write additional match rules that the user didn't specify. (Though I do agree that could be painful to implement.)

I would love it if MAAS didn't need to send in the MAC at all. Unfortunately, I don't think this is viable long-term, as the kernel, plus algorithms for determining interface names, will change over time. The only stable match criteria we have been able to rely on across all distros and releases that MAAS supports is the MAC.

(2) We cannot easily add driver matching to MAAS. This would be tricky/undesired for a number of reasons:
 - The driver the kernel uses could change over time.
 - This would be a schema change that we could land for MAAS 2.6 at the earliest. (Unless we employ inefficient hacks to avoid that.)
 - This would require adding at least a post-commissioning hook to MAAS, and possibly another commissioning script, in order to gather the additional match parameters.

That said, I think to some degree it's not great for MAAS to only match on MAC address. (This can get tricky, for example, if we're deploying to a bridge NIC where each port has the name MAC but appears as multiple interfaces.)

(3) The reason MAAS assigns a physical MAC to a bond interface is due to issues that have occurred in the past that require it. For example, you may have a DHCP server that begins handing out a different lease to a bond, when we expected it to get the same address as the physical interface (for example, if the machine was recently PXE booted from one of the bond interfaces). For this (and possibly other reasons that are escaping me) our users generally aren't fans of unstable MAC addresses across deployments of the same hardware.

My $0.02: if Netplan can gather any additional criteria it needs to apply more specific rules at "apply" time to "ethernets" defined based solely on the MAC, that would be preferred to the current behavior.