Red Hat Bugzilla – Bug 1384937
[NMCI] team activation timeout with incorrect setup
Last modified: 2017-08-01 05:19:37 EDT
Description of problem: two tests fails on s390x (some of these are on ppc64le too) in one I am passing: nmcli connection modify team0 team.config '{ "device": "nm-team", "runner": {"name": "activebalance"}}' and in the second in nmcli editor I set: set team.config {\"blah\":1,\"blah\":2,\"blah\":3} Version-Release number of selected component (if applicable): NetworkManager-1.4.0-12.el7 How reproducible: always
Hi, I think this is already solved by commit: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-1-4&id=d5b3bf8ee760c7cda5daf762fe14bbe734d5d1a1 The commit prevents the loss of d-bus events related to the connection which is activating. Vladimir, can you please try again those tests building NM from the nm-1-4 upstream branch? Thanks!
I consider this issue solved as team CI tests are now consistently passing on s390x.
I think I see a slightly different behaviour but definitely connected to this one on RHEL. [root@qe-dell-ovs5-vm-43 NetworkManager]# nmcli connection add type team con-name team0 team.config '{"blah":1,"blah":2,"blah":3}' Connection 'team0' (b26704f3-d553-41d0-989d-45759f94edde) successfully added. [root@qe-dell-ovs5-vm-43 NetworkManager]# nmcli connection add type team-slave ifname eth1 con-name team0.0 master nm-team Connection 'team0.0' (b4725808-ab41-4109-9e8c-afbecbc6b8b1) successfully added. [root@qe-dell-ovs5-vm-43 NetworkManager]# nmcli device DEVICE TYPE STATE CONNECTION eth0 ethernet connected testeth0 eth1 ethernet connected team0.0 nm-team team connected team0 eth10 ethernet disconnected -- [root@qe-dell-ovs5-vm-43 NetworkManager]# ip a s 4: eth1@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master nm-team state UP qlen 1000 link/ether d2:f8:0d:7c:19:8a brd ff:ff:ff:ff:ff:ff link-netnsid 0 98: nm-team: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000 link/ether d2:f8:0d:7c:19:8a brd ff:ff:ff:ff:ff:ff inet 192.168.100.31/24 brd 192.168.100.255 scope global dynamic nm-team valid_lft 214sec preferred_lft 214sec inet6 fe80::9b41:aa59:b4f0:b952/64 scope link valid_lft forever preferred_lft forever [root@qe-dell-ovs5-vm-43 NetworkManager]# teamdctl nm-team state dump { "ports": { "eth1": { "ifinfo": { "dev_addr": "d2:f8:0d:7c:19:8a", "dev_addr_len": 6, "ifindex": 4, "ifname": "eth1" }, "link": { "duplex": "full", "speed": 10000, "up": true }, "link_watches": { "list": { "link_watch_0": { "delay_down": 0, "delay_up": 0, "down_count": 0, "name": "ethtool", "up": true } }, "up": true } } }, "setup": { "daemonized": false, "dbus_enabled": true, "debug_level": 2, "kernel_team_mode_name": "roundrobin", "pid": 7140, "pid_file": "/var/run/teamd/nm-team.pid", "runner_name": "roundrobin", "zmq_enabled": false }, "team_device": { "ifinfo": { "dev_addr": "d2:f8:0d:7c:19:8a", "dev_addr_len": 6, "ifindex": 98, "ifname": "nm-team" } } } logs attached
Created attachment 1281091 [details] debug logs
The configuration: '{"blah":1,"blah":2,"blah":3}' is technically a valid JSON but teamd doesn't accept it directly because there are duplicate keys. NM now rewrites the configuration in order to pass a MAC address to teamd, and when rewriting also sanitizes it removing duplicate keys. Note that teamd ignores any unknown key and so the resulting configuration: {"blah": 3, "hwaddr": "26:41:8F:CE:F6:34"} is valid for teamd. In my opinion this is fine and there is nothing to change in NM. Vladimir, what do you think?
*** Bug 1455130 has been marked as a duplicate of this bug. ***
Team is now correctly upped as invalid options are ignored.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2299