To ensure that we understand the consequences of these changes, I've spent a bit of time tracking down everywhere this will affect in cloud-init by looking up the various call chains of `get_interfaces`:
Called by:
* `_get_current_rename_info`
* `_rename_interfaces`
* `apply_network_config_names`
* `Distro.apply_network_config_names`
* `Init._apply_netcfg_names`
* `Init.apply_network_config`
* `get_ib_hwaddrs_by_interface`
* `helpers.openstack.convert_net_json`
* {`ConfigDrive`, `OpenStack`, `IBMCloud`}`.network_config`
* `get_interfaces_by_mac_on_linux`
* `get_interfaces_by_mac`
* `OpenNebulaNetwork` -- used to determine physical NICs for network config generation
* Oracle -- a couple of ways in network config generation
* EC2 -- network config conversion (theirs to ours)
* `helpers.openstack.convert_net_json`
* `helpers.digitalocean.convert_network_configuration`
* `helpers.upcloud.convert_to_network_config_v1`
* `net.get_devicelist` (but only on FreeBSD)
* `find_fallback_nic_on_netbsd_or_openbsd`
* `find_fallback_nic_on_freebsd`
* `Networking.wait_for_physdevs`
* `Init.apply_network_config`
Most of these are related to converting a network configuration format provided by a cloud into our own formats. None of this generation includes handling for creating OVS config (unsurprisingly!), so those cases should all be unaffected by changes to `get_interfaces` around OVS (except for a very minor performance hit for any new checks). Others are only used on *BSD, so we also don't need to worry about OVS interfaces there.
Every other call originates from `Init.apply_network_config`: this is the codepath that we are intending to affect, so we can see that there shouldn't be any unexpected consequences in other parts of the codebase.
To ensure that we understand the consequences of these changes, I've spent a bit of time tracking down everywhere this will affect in cloud-init by looking up the various call chains of `get_interfaces`:
Called by: rename_ info` interfaces` network_ config_ names` apply_network_ config_ names` apply_netcfg_ names` network_ config` hwaddrs_ by_interface` openstack. convert_ net_json` }`.network_ config` _by_mac_ on_linux` _by_mac` openstack. convert_ net_json` digitalocean. convert_ network_ configuration` upcloud. convert_ to_network_ config_ v1` devicelist` (but only on FreeBSD) nic_on_ netbsd_ or_openbsd` nic_on_ freebsd` wait_for_ physdevs` network_ config`
* `_get_current_
* `_rename_
* `apply_
* `Distro.
* `Init._
* `Init.apply_
* `get_ib_
* `helpers.
* {`ConfigDrive`, `OpenStack`, `IBMCloud`
* `get_interfaces
* `get_interfaces
* `OpenNebulaNetwork` -- used to determine physical NICs for network config generation
* Oracle -- a couple of ways in network config generation
* EC2 -- network config conversion (theirs to ours)
* `helpers.
* `helpers.
* `helpers.
* `net.get_
* `find_fallback_
* `find_fallback_
* `Networking.
* `Init.apply_
Most of these are related to converting a network configuration format provided by a cloud into our own formats. None of this generation includes handling for creating OVS config (unsurprisingly!), so those cases should all be unaffected by changes to `get_interfaces` around OVS (except for a very minor performance hit for any new checks). Others are only used on *BSD, so we also don't need to worry about OVS interfaces there.
Every other call originates from `Init.apply_ network_ config` : this is the codepath that we are intending to affect, so we can see that there shouldn't be any unexpected consequences in other parts of the codebase.