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