Comment 8 for bug 1912844

Revision history for this message
Dan Watkins (oddbloke) wrote :

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
[1] https://github.com/canonical/cloud-init/blob/master/cloudinit/net/__init__.py#L855
[2] https://github.com/canonical/cloud-init/blob/master/cloudinit/net/__init__.py#L523
[3] https://github.com/canonical/cloud-init/blob/master/cloudinit/net/__init__.py#L268

(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.)