Comment 16 for bug 1804861

It doesn't matter which process we use, it will be a big SRU regardless.

Also, of course it's an easy fix in MAAS, and it obviously works. I've shown that setting no "macaddress" field in the netplan syntax does what it should. Just don't specify a default for that value, and don't write the macaddress field in the generated config.

The behavior that happens in kernel is largely irrelevant; because that would be skipped anyway through the use of networkd, which will do its own MAC address handling. You do not need to, and definitely should not, attempt to be clever and provide default values for optional fields unless you really know what the behavior will be, or somehow really need to override the behavior of what is authoritative on the network management -- that's networkd and netplan.

Sure, the current kernel behavior is to use the first phy, that's fine, but not something that needs to be emulated in userland as well. It could have been fine, if it wasn't for networkd matching devices incorrectly, which is (the matching) a bug that needs to be fixed. Similarly, the fact that the kernel needs patching shouldn't be a blocker for fixing the issue (missing DEVTYPE).

Now, I *am* looking at a suitable "workaround" in netplan, but as expressed before, this is a *workaround* to work around MAAS/juju/curtin writing default values it doesn't need to write, based on assumptions that may be correct for the kernel, but do not need to be repeated in userland. I don't have the solution right now, but the options for matching are basically limited to MACAddress=, OriginalName=, Path=, Driver= and Type=. Others aren't useful.

Working from this, MACAddress= is already out of the question -- it's where the issue comes from.

OriginalName= is largely irrelevant, we don't necessarily know this to begin with.

Type= is not useful at all; DEVTYPE= isn't set for ethernets, as discussed earlier.

Path= is not especially great, no useful ID_PATH available on the bond, but physical devices do set something (ID_PATH=pci-0000:00:06.0 / ID_PATH=pci-0000:00:07.0). Possibly could be used, but that will break/become extremely complicated if we try to match against a glob.

To be clear: my concern isn't just this particular use case of deployment via MAAS. I want this to work correctly in all cases, and I think the least complicated way to get to that point is to not specify the MAC address when defining the bond, or defining one that is different from the permanent physical MAC of the underlying devices, or explicitly matching on other values than the MAC address.

The point is: if I just workaround in netplan, the other issues won't get fixed. Please make sure you prioritize fixing the various configuration generators such that they stop making the wrong assumptions they are making.