cannot reproduce. 

variant a) I have legacy cluster + host in it. I update cluster to ovs, this makes mgmt network out of sync, I press sync and this is what generateNetworks() in HostSetupNetworksVDSCommand generates:

networks = {HashMap@21097}  size = 1
 0 = {HashMap$Node@21159} "ovirtmgmt" -> " size = 11"
  key = "ovirtmgmt"
  value = {HashMap@21105}  size = 11
   0 = {HashMap$Node@21112} "netmask" -> "255.255.252.0"
   1 = {HashMap$Node@21113} "ipv6autoconf" -> "true"
   2 = {HashMap$Node@21114} "nic" -> "em1"
   3 = {HashMap$Node@21115} "bridged" -> "true"
   4 = {HashMap$Node@21116} "ipaddr" -> "10.34.63.167"
   5 = {HashMap$Node@21117} "defaultRoute" -> "true"
   6 = {HashMap$Node@21118} "dhcpv6" -> "false"
   7 = {HashMap$Node@21119} "STP" -> "no"
   8 = {HashMap$Node@21120} "gateway" -> "10.34.63.254"
   9 = {HashMap$Node@21121} "mtu" -> "1500"
   10 = {HashMap$Node@21142} "switch" -> "ovs"


… for me, when I pass this …Parameters input to it:


{"networks":{ovirtmgmt={netmask=255.255.252.0, ipv6autoconf=true, nic=em1, bridged=true, ipaddr=10.34.63.167, defaultRoute=true, dhcpv6=false, STP=no, gateway=10.34.63.254, mtu=1500, switch=ovs}},"bondings":{},"options":{connectivityTimeout=120, connectivityCheck=true}}



b) … but lets try another flow. I removed host mentioned above, changed cluster level to ovs, add host. Mgmt network out of sync (weird, probably vdsm bug?), but lets ignore it, go into setupnetworks dialog, check 'sync' so we can proceed, update gateway address, confirm. Very similar listing as one above, changes are reflected and gateway is not empty.


==> can you provide more details how to reproduce? Starting with totally fresh environment, which you describe to me? (I have fresh install, cluster has this setting, host ... and then I ...)

Hello Martin,

- First of all, don't move host from legacy cluster to 'ovs' cluster, it's not working yet and not supported yet(when you do something like that on current versions, networks still remain as linux bridges..). 

- You need to start with adding the host into an 'ovs' cluster from the beginning..without switching cluster types.

1) Add host to 'ovs' switch type cluster
2) Attach network via setup networks dialog with static ip and gateway

- Engine send 'null' for ipv4Gateway

maybe I explained myself badly. I already did this in b) part. I tried to do it once again, though. Here's full log:

1. fresh installation
2. changed cluster switch type to ovs
3. add new host (mgmt rendered out of sync. Wrong, probably vdsm fault)
4. added new network
5. created dummy interface
6. refresh capabilities (mgmt still out of sync, dummy found)
7. attached network to dummy, specified static ip configuration with certain gateway, confirmed
7.5 break point hit before invoding vdsm command, gateway is specified in NetworkAttachment incomming from client and reaches vdsbroder, which correctly sets 'gateway' field in map. There seems to be no error at all.
8. operation fails, due to vdsm error, claiming, that not all interfaces uses ovs — this will be related to out of sync mgmt network mentioned before, and is not cause of your fault. So I'd assume, that vdsm is not functional in ovs area at this moment.

I'm not able to reproduce this bug, contrary, I see evidence, that this is not happening.

Hi Martin,

Why you assigned the bug on me? please change it back.

I don't understand what you are doing and why you end up as out-of-sync. It doesn't sound good to me.

Please don't change the cluster switch type. Create a new cluster as 'ovs' type and then add host to this cluster! without switching the type.
Start as new ovs cluster.

Please contact me offline and i will give you my setup. Thanks.

(sorry for assignment)
I'm currently working on more urgent things and am able to test this only on recent master. I'll try to retest on 4.0.6, but I'd be very surprised if results are different.

± fresh installation -> new ovs cluster -> new host -> new network etc. everything is same as described in #3 except that new cluster was created instead of default one updated. Unable to reproduce on master.

I'll try 4.0.6 tomorrow, when I can build different version without blocking work on other bugs/rfe.

same behavior on 4.0.6 as reported yesterday on master. Details:


produced option map in org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand:

networks = {HashMap@21399}  size = 1
 0 = {HashMap$Node@21403} "ooo" -> " size = 10"
  key = "ooo"
  value = {HashMap@21405}  size = 10
   0 = {HashMap$Node@21409} "netmask" -> "255.255.255.0"
   1 = {HashMap$Node@21410} "ipv6autoconf" -> "false"
   2 = {HashMap$Node@21411} "nic" -> "dummy_30"
   3 = {HashMap$Node@21412} "bridged" -> "true"
   4 = {HashMap$Node@21413} "ipaddr" -> "192.168.2.2"
   5 = {HashMap$Node@21414} "dhcpv6" -> "false"
   6 = {HashMap$Node@21415} "STP" -> "no"
   7 = {HashMap$Node@21416} "gateway" -> "192.168.2.3"
   8 = {HashMap$Node@21417} "mtu" -> "1500"
   9 = {HashMap$Node@21418} "switch" -> "ovs"


supervdsm.log:
   MainProcess|jsonrpc/0::DEBUG::2016-11-29 10:38:37,503::api::247::root::(setupNetworks) Setting up network according to configuration: networks:{u'ooo': {u'ipv6autoconf': False, u'nic': u'dummy_30', u'ipaddr': u'192.168.2.2', u'netmask': u'255.255.255.0', u'mtu': 1500, u'switch': u'ovs', u'dhcpv6': False, u'STP': u'no', u'bridged': u'true', u'gateway': u'192.168.2.3'}}, bondings:{}, options:{u'connectivityCheck': u'true', u'connectivityTimeout': 120}



again failure to finish setupnetworks, with this error in supervdsm.log:
 Error in setupNetworks
Traceback (most recent call last):
  File "/usr/share/vdsm/supervdsmServer", line 94, in wrapper
    res = func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/network/api.py", line 259, in setupNetworks
    _change_switch_type(networks, bondings, options, running_config)
  File "/usr/lib/python2.7/site-packages/vdsm/network/api.py", line 288, in _change_switch_type
    netswitch.validate_switch_type_change(networks, bondings, running_config)
  File "/usr/lib/python2.7/site-packages/vdsm/network/netswitch.py", line 415, in validate_switch_type_change
    'All networks must be reconfigured on switch type change')
ConfigNetworkError: (21, 'All networks must be reconfigured on switch type change')

This is very odd - mmucha cannot reproduce this bug.

Michael, could you try it again, with and 4.1 Engine+Vdsm, maybe on a fresh environment?

Yes, i tried on latest 4.1.0-0.2.master.20161205231208.gitf0af92b.el7.centos and i still always end up as the network is out-of-sync cause of the gateway.

But now it is seems that engine is sending -
ipv4Address='5.5.5.6', ipv4Netmask='24', ipv4Gateway='5.5.5.254'
but vdsm gets  

MainProcess|jsonrpc/6::DEBUG::2016-12-06 15:46:17,353::supervdsmServer::92::SuperVdsm.ServerCallback::(wrapper) call setupNetworks with ({}, {'connectivityCheck': 'true', 'connectivityTimeout': 120}) {}
MainProcess|jsonrpc/6::DEBUG::2016-12-06 15:46:17,353::api::247::root::(setupNetworks) Setting up network according to configuration: networks:{'n2': {'ipv6autoconf': True, 'nic': 'enp6s0', 'mtu': 1500, 'switch': 'ovs', 'dhcpv6': False, 'STP': 'no', 'bridged': 'true'}}, bondings:{}, options:{'connectivityCheck': 'true', 'connectivityTimeout': 120}

MainProcess|jsonrpc/6::INFO::2016-12-06 15:46:19,072::netconfpersistence::58::root::(setNetwork) Adding network n2({'ipv6autoconf': True, 'nameservers': [], 'nic': 'enp6s0', 'mtu': 1500, 'switch': 'ovs', 'dhcpv6': False, 'stp': False, 'bridged': True, 'defaultRoute': False})

MainProcess|jsonrpc/6::INFO::2016-12-06 15:46:20,205::netconfpersistence::137::root::(save) Saved new config RunningConfig({'ovirtmgmt': {u'ipv6autoconf': True, u'nameservers': [u'10.35.64.1'], u'nic': u'enp4s0', u'mtu': 1500, u'switch': u'ovs', u'dhcpv6': False, u'stp': False, u'bridged': True, u'defaultRoute': True, u'bootproto': u'dhcp'}, 'n2': {'ipv6autoconf': True, 'nameservers': [], 'nic': 'enp6s0', 'mtu': 1500, 'switch': 'ovs', 'dhcpv6': False, 'stp': False, 'bridged': True, 'defaultRoute': False}}

u'n2': {'ipv6autoconf': True, 'addr': '', 'ipv4defaultroute': False, 'ipv6addrs': [], 'mtu': 1500, 'dhcpv4': False, 'netmask': '', 'dhcpv6': False, 'stp': False, 'ipv4addrs': [], 'gateway': ''

all setupNetworks with ({}, {'connectivityCheck': 'true', 'connectivityTimeout': 120}) {}
MainProcess|jsonrpc/3::DEBUG::2016-12-06 15:48:08,251::api::247::root::(setupNetworks) Setting up network according to configuration: networks:{'n2': {'ipv6autoconf': True, 'nic': 'enp6s0', 'ipaddr': '5.5.5.6', 'prefix': '24', 'mtu': 1500, 'switch': 'ovs', 'dhcpv6': False, 'STP': 'no', 'bridged': 'true', 'gateway': '5.5.5.254'}}

MainProcess|jsonrpc/7::DEBUG::2016-12-06 15:48:12,009::supervdsmServer::99::SuperVdsm.ServerCallback::(wrapper) return network_caps with {'bridges': {u'ovirtmgmt': {'ipv6autoconf': True, 'addr': '10.35.128.18', 'ipv4defaultroute': True, 'ipv6addrs': ['2620:52:0:2380:221:5eff:fe3f:deb0/64'], 'mtu': 1500, 'dhcpv4': True, 'netmask': '255.255.255.0', 'dhcpv6': False, 'stp': False, 'ipv4addrs': ['10.35.128.18/24'], 'gateway': '10.35.128.254', 'ipv6gateway': 'fe80:52:0:2380::fe', 'ports': [u'enp4s0']}, u'n2': {'ipv6autoconf': True, 'addr': '5.5.5.6', 'ipv4defaultroute': False, 'ipv6addrs': [], 'mtu': 1500, 'dhcpv4': False, 'netmask': '255.255.255.0', 'dhcpv6': False, 'stp': False, 'ipv4addrs': ['5.5.5.6/24'], 'gateway': '',


networks = {'n2': {'addr': '5.5.5.6',
                           'bond': '',
                           'bridged': True,
                           'dhcpv4': False,
                           'dhcpv6': False,
                           'gateway': '',
                           'iface': 'n2',
                           'ipv4addrs': ['5.5.5.6/24'],
                           'ipv4defaultroute': False,

Maybe now it vdsm to blame.

If the parameter is passed to Vdsm, then we are simply seeing another instance of bug 1383035.

Please reopen if I missed something.

*** This bug has been marked as a duplicate of bug 1383035 ***