Comment 31 for bug 1912844

> Interfaces of type 'internal' may be used for other things than VLANs so depending on what you want to match on it may or may not be precise enough.

So the cloud-init code in question is used in a couple of (relevant) ways: (a) to determine the state of any physical interfaces for which we should wait before proceeding to apply network configuration to the system (intended for the case where network devices have not yet been detected by the kernel, for a variety of reasons), and (b) to determine the current system state when renaming any such interfaces to match the specified network configuration.

The code in question is iterating through every interface in the system (as determined from /sys/class/net) and determining if it should be included in this set. For reference, the code excludes bridges, VLANs, bonds, any device that has a `/master` symlink that isn't a bridge/bond member, NET_FAILOVER devices, devices without a MAC, devices with a "stolen" MAC, and, on some clouds, interfaces owned by a particular device driver (the one case I recall is for Mellanox interfaces on Azure).

We're looking to answer the question of "is this interface one that cloud-init needs to know about", so I think what we want is to exclude any OVS interface that doesn't originate from the system: OVS will handle naming non-system interfaces correctly and we know that, even if currently absent, they will be present once "needed" (because OVS will create them).

> Interfaces of type 'dpdk' would probably be invisible from the kernel
> sysfs and netlink interfaces pov, interfaces of type 'system' have
> their origin in the system and cloud-init would most likely already
> know all about them. Interfaces of type 'internal' may be used for
> other things than VLANs so depending on what you want to match on it
> may or may not be precise enough.

This suggests to me that internal interfaces _are_ the right ones exclude. I considered excluding _all_ non-"system" interfaces, but in the example config we've been using here, I see:

# ovs-vsctl --columns type find interface name=bond0
type : ""

We'd exclude the bond0 interface anyway (for being a bond) but it makes me wonder if there are other interfaces that we _wouldn't_ otherwise exclude that won't have type=system. To avoid having to answer that, I think we can safely limit this to internal interfaces (as addressing this problem, and likely a class of related ones) and if we find cases that this doesn't cover then we can drive the required changes at that point.

> In the Ubuntu systemd service <snip>

Thanks, this is a bunch of useful info! I'll experiment with a few of these options.