Bug 1384937 - [NMCI] team activation timeout with incorrect setup
Summary: [NMCI] team activation timeout with incorrect setup
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
: 1455130 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-14 11:45 UTC by Vladimir Benes
Modified: 2017-08-01 09:19 UTC (History)
9 users (show)

Fixed In Version: NetworkManager-1.8.0-0.2.git20170215.1d40c5f4.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 09:19:37 UTC


Attachments (Terms of Use)
debug logs (118.67 KB, text/plain)
2017-05-22 14:36 UTC, Vladimir Benes
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2299 normal SHIPPED_LIVE Moderate: NetworkManager and libnl3 security, bug fix and enhancement update 2017-08-01 12:40:28 UTC

Description Vladimir Benes 2016-10-14 11:45:55 UTC
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

Comment 2 Beniamino Galvani 2016-10-14 14:51:21 UTC
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!

Comment 4 Beniamino Galvani 2017-01-02 08:57:37 UTC
I consider this issue solved as team CI tests are now consistently passing on s390x.

Comment 6 Vladimir Benes 2017-05-22 14:35:58 UTC
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

Comment 7 Vladimir Benes 2017-05-22 14:36:24 UTC
Created attachment 1281091 [details]
debug logs

Comment 8 Beniamino Galvani 2017-05-22 15:33:52 UTC
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?

Comment 9 Vladimir Benes 2017-05-30 15:35:11 UTC
*** Bug 1455130 has been marked as a duplicate of this bug. ***

Comment 11 Vladimir Benes 2017-06-02 07:35:12 UTC
Team is now correctly upped as invalid options are ignored.

Comment 12 errata-xmlrpc 2017-08-01 09:19:37 UTC
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


Note You need to log in before you can comment on or make changes to this bug.