Comment 27 for bug 1912844

> But I guess it would be reasonable to split the work up in bite sized chunks as long as we allow for supporting this in the design.

Having looked a little more, I don't think an incremental approach buys us much here: we'd have to replace the `udevadm` code with `ovs-vsctl` code in the next stage anyway (rather than extending it). We may as well just take the approach that will address both in the first place.

The next question is exactly which interfaces we should be excluding from the set of interfaces we consider. At the moment, my POC is excluding interfaces whose name matches an OVS bridge, determined via `ovs-vsctl list-br`. In an instance with an additional VLAN to the above configurations, I see:

# ovs-vsctl list-br
ovs-br
ovs-br.100
ovs-br.200

Does this seems appropriate? I also notice that querying for internal interfaces returns the same set:

# ovs-vsctl find interface type=internal | grep ^name
name : ovs-br
name : ovs-br.200
name : ovs-br.100

I don't think we want to exclude every interface known to OVS, because I believe that would regress bug 1898997. From an instance launched from the integration test for that bug:

cb6840fc-f53d-471b-b7e7-aa7398fd4c37
    Bridge ovs-br
        fail_mode: standalone
        Port enp5s0
            Interface enp5s0
        Port ovs-br
            Interface ovs-br
                type: internal
    ovs_version: "2.13.1"

We _do_ still want to consider enp5s0 in cloud-init's code, because it's a real interface that isn't (entirely?) configured by OVS.

Thoughts? (If this isn't a sufficient problem description, let me know!)