OK, I have a suspicion of what's going on here. I've compared two systems: one launched with the network config above (and updated/rebooted), and one launched with that config minus the "openvswitch: {{}}" line.
When I compare /sys/class/net/ovs-br.100/addr_assign_type in the two systems, I see that on the OpenVSwitch-enabled system, it is 3 ("set using dev_set_mac_address") whereas in the non-OVS system, it is 2 ("stolen from another device"). (Descriptions of those values come from https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net.)
The function which raises the exception (get_interfaces_by_mac_on_linux[0]) calls get_interfaces[1] to get the list of interfaces it should consider. get_interfaces will exclude all interfaces with an addr_assign_type of 2 (via interface_has_own_mac[2]). It will also explicitly exclude VLANs (via is_vlan[3], which checks for DEVTYPE=vlan in /sys/class/net/<iface>/uevent): this check is also not triggered because the /uevent on the OVS system does not have DEVTYPE=vlan in it.
I'm not particularly familiar with OVS: is it somehow expected that this VLAN will not be presented via /sys/class/net as other VLANs are? Or does this suggest that there's a bug in something below cloud-init which isn't correctly configuring this VLAN (which cloud-init then cannot detect as a VLAN, and so fails)?
OK, I have a suspicion of what's going on here. I've compared two systems: one launched with the network config above (and updated/rebooted), and one launched with that config minus the "openvswitch: {{}}" line.
When I compare /sys/class/ net/ovs- br.100/ addr_assign_ type in the two systems, I see that on the OpenVSwitch-enabled system, it is 3 ("set using dev_set_ mac_address" ) whereas in the non-OVS system, it is 2 ("stolen from another device"). (Descriptions of those values come from https:/ /www.kernel. org/doc/ Documentation/ ABI/testing/ sysfs-class- net.)
The function which raises the exception (get_interfaces _by_mac_ on_linux[ 0]) calls get_interfaces[1] to get the list of interfaces it should consider. get_interfaces will exclude all interfaces with an addr_assign_type of 2 (via interface_ has_own_ mac[2]) . It will also explicitly exclude VLANs (via is_vlan[3], which checks for DEVTYPE=vlan in /sys/class/ net/<iface> /uevent) : this check is also not triggered because the /uevent on the OVS system does not have DEVTYPE=vlan in it.
I'm not particularly familiar with OVS: is it somehow expected that this VLAN will not be presented via /sys/class/net as other VLANs are? Or does this suggest that there's a bug in something below cloud-init which isn't correctly configuring this VLAN (which cloud-init then cannot detect as a VLAN, and so fails)?
[0] https:/ /github. com/canonical/ cloud-init/ blob/master/ cloudinit/ net/__init_ _.py#L831 /github. com/canonical/ cloud-init/ blob/master/ cloudinit/ net/__init_ _.py#L855 /github. com/canonical/ cloud-init/ blob/master/ cloudinit/ net/__init_ _.py#L523 /github. com/canonical/ cloud-init/ blob/master/ cloudinit/ net/__init_ _.py#L268
[1] https:/
[2] https:/
[3] https:/
(As an aside: both my understanding of the problem and a test of a revert suggest that this isn't a regression caused by https:/ /bugs.launchpad .net/ubuntu/ +source/ cloud-init/ +bug/1912844.)