Comment 2 for bug 1788756

Yes, we already uses these networks for backwards compatibility. We didn't plan to change this, although arguably we might now be able to make a better decision - so we should think about it.

However, if neither a "default" or "maas" network exists, we should fall back to attaching to a bridge known to be attached to a DHCP-enabled network.

In the absence of anything else, MAAS should always be able to make some type of macvlan or bridge attachment; the only question is whether or not it will actually /work/. ;-) In the case of macvlan, if the controller resides on the same host as libvirt, the booting node won't be able to contact it unless the macvlan is configured for hairpin (vepa) mode on the attached switch. (That is, unless we have a secondary rack active on the VLAN - but that's another story.)

The other problematic thing with macvlan is that it may not work inside of a container, since it creates a tun/tap device for communication, which may or may not be allowed depending on the container's settings (and even if it's allowed, I've seen cases where it can't find the device file).