@Dan, was this released to focal in the end? Thanks!
--
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
On Tue, Mar 23, 2021 at 07:53:59AM -, Alfonso Sanchez-Beato wrote:
> Is this going to be backported to focal (see LP: #1919493)?
Yep, the SRU process has been started already.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Is this going to be backported to focal (see LP: #1919493)?
--
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
This bug was fixed in the package cloud-init -
21.1-19-gbad84ad4-0ubuntu1
---
cloud-init (21.1-19-gbad84ad4-0ubuntu1) hirsute; urgency=medium
* d/cloud-init.postinst: Change output log permissions on upgrade
(LP: #1918303)
* New upstream snapshot.
- .travis.yml: generate
> 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
> Another question: is there a canonical way to determine if OVS isn't
up? Currently I'm trying to execute a command and looking for "database
connection failed" in the output, is that appropriate?
In the Ubuntu systemd service we assess the database socket:
> 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
Another question: is there a canonical way to determine if OVS isn't up?
Currently I'm trying to execute a command and looking for "database
connection failed" in the output, is that appropriate?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
> 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
With the latest update to the PPA [0] I can deploy a full OpenStack with
machines with two VLAN interfaces each and respective spaces.
For an OVN deploy this currently requires two PPAs [0] and [1].
[0] https://launchpad.net/~oddbloke/+archive/ubuntu/lp1912844
[1]
Running with Dan's PPA [0] on the final reboot cloud-init fails with the
following. See attached image.
Stderr: ovs-vsctl: unix:/var/run/openvswitch/db.sock: database
connection failed (No such file or directory)
I'll try and get the rest of the error content (not from console) for
further
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`
*
Hello Dan,
> It looks to me like these two statements are in opposition: if OVS is
> managing an interface via a different datapath, then it won't have
> ID_NET_DRIVER=openvswitch in its `udevadm info`.
>
> If this is the case, then I think we have a couple of options.
That is correct, I
Hey Frode,
Now moving on from the "does this system have any OVS-managed
interfaces?" to "how can I tell if a particular interface is managed by
OVS?":
We discussed using `udevadm info` to determine if an interface is OVS-
managed:
> If it is sufficient to know that this is a Open vSwitch
I've figured out why my LXD reproducer doesn't reproduce exactly:
NoCloud runs at both local and net stages, so the code in question is
called earlier in boot than the OpenStack data source is. For now, I'll
proceed with the synthetic reproducer: calling the Python code which
fails directly.
--
So I would think it to be odd to not have `ovs-vsctl` available if
you're running Open vSwitch, but as you point out we have no way of
knowing how or where other distributions or image builders would think
to put the binary, so that is a fair point.
I'm leaning towards specifically checking for
> The default `datapath_type` is 'system', so if it is not explicitly
specified for a bridge it will not be visible in `ovs-vsctl show`
output, but 'system' will still be the `datapath_type` used.
Great, I figured it wasn't material.
> You can query Open vSwitch at runtime for which datapath
The default `datapath_type` is 'system', so if it is not explicitly
specified for a bridge it will not be visible in `ovs-vsctl show`
output, but 'system' will still be the `datapath_type` used.
If you configure a system where all bridges have `datapath_type`
'netdev' /sys/class/net/ovs-system
** Changed in: cloud-init (Ubuntu)
Status: New => In Progress
--
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
Thanks Frode, that's really helpful!
I don't see the `datapath_type` in my output:
e2d9c9b4-739c-4333-a372-4d46585fcfb9
Bridge ovs-br
fail_mode: standalone
Port ovs-br
Interface ovs-br
type: internal
Port bond0
Interface bond0
Those subprocess calls do indeed add up to be expensive quite quickly,
and when I think of it it may actually not be a consistent way of
determining if a interface belongs to Open vSwitch in all its
configurations. Open vSwitch supports multiple datapath types, and
depending on which one you use
I can confirm that udev does report the VLAN as OVS-managed:
# udevadm info /sys/class/net/ovs-br.100
P: /devices/virtual/net/ovs-br.100
L: 0
E: DEVPATH=/devices/virtual/net/ovs-br.100
E: INTERFACE=ovs-br.100
E: IFINDEX=5
E: SUBSYSTEM=net
E: USEC_INITIALIZED=4703175
E: ID_MM_CANDIDATE=1
E:
fwiw; Open vSwitch do distribute Python client libraries [0], but they
may be a bit complex for this simple use case. We do maintain a
SimpleOVSDB interface [1] and there is an example of how it could be
used to iterate over stuff [2]. Feel free to use, steal or whatever
suits your needs :)
0:
Particulars about what role a Open vSwitch port/interface has is
unfortunately not exposed through sysfs nor iproute2 tools POV. Open
vSwitch and its data path driver would manage that based on
configuration stored in Open vSwitch.
If it is sufficient to know that this is a Open vSwitch managed
On Fri, Jan 22, 2021 at 10:51:25PM -, Ryan Harper wrote:
> Thanks for doing most of the digging here @Oddbloke; I suspect as with
> bond and bridges for ovs, we'll need a special case to check if a vlan
> entry is also OVS, much like we did for bonds/bridges:
>
>
On Fri, Jan 22, 2021 at 10:48:56PM -, David Ames wrote:
> I am not sure I have any definitivie answers but here are my thoughts.
>
> Compare a VLAN device created with `ip link add`
>
> ip link add link enp6s0 name enp6s0.100 type vlan id 100
>
> cat /sys/class/net/enp6s0.100/uevent
>
Thanks for doing most of the digging here @Oddbloke; I suspect as with
bond and bridges for ovs, we'll need a special case to check if a vlan
entry is also OVS, much like we did for bonds/bridges:
https://github.com/canonical/cloud-init/pull/608/files
So our is_vlan change will need to see if
I am not sure I have any definitivie answers but here are my thoughts.
Compare a VLAN device created with `ip link add`
ip link add link enp6s0 name enp6s0.100 type vlan id 100
cat /sys/class/net/enp6s0.100/uevent
DEVTYPE=vlan
INTERFACE=enp6s0.100
IFINDEX=3
To an OVS VLAN interface created
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
Also of note: the MAC address being reported as duplicated in both the
reported log and in the exception I see is not present in the specified
configuration. It's presumably being generated by OVS and applied to
ovs-br (and therefore inherited by ovs-br.100?). I'm going to see if a
more minimal
The network config below closely reproduces the issue when a LXD VM is
launched with it, has openvswitch-switch installed on it (e.g. via a
manual DHCP on enp5s0), and is `cloud-init clean --logs --reboot`ed.
The log does not contain the error message, but calling
Cloud init version:
$ dpkg -l |grep cloud-ini
ii cloud-init 20.4.1-0ubuntu1~20.04.1 all
initialization and customization tool for cloud instances
ii cloud-initramfs-copymods 0.45ubuntu1 all
copy initramfs
This is the network config, pulled out of the log file:
bonds:
bond0:
interfaces:
- enp1s0
- enp7s0
macaddress: 52:54:00:28:fd:fd
mtu: 1500
parameters:
down-delay: 0
gratuitious-arp: 1
mii-monitor-interval: 0
mode: active-backup
** Attachment added: "Screenshot from 2021-01-22 12-02-05.png"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+attachment/5455815/+files/Screenshot%20from%202021-01-22%2012-02-05.png
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Screen capture of the network config in MAAS
--
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
35 matches
Mail list logo
