> 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!)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1912844
Title:
Bond with OVS bridging RuntimeError: duplicate mac found!
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
