Description of problem: When user creates a gluster network and attaches it to the interface, address for that interface does not show up. To get the address user has to perform Refresh Capabilities on the node. Version-Release number of selected component (if applicable): ovirt-engine-3.6.0-0.0.master.20150420232310.gite30f655.el6.noarch How reproducible: Always Steps to Reproduce: 1. Add a host with two interfaces to the system. 2. create a network called gluster network. 3. Now from the setup Host network dialog attach this network to the nic which is free. Actual results: user will not be able to see that the address is updated in the Network Interfaces sub tab until he performs refresh capabilities on that node. Expected results: User should be able to see that the address is updated in the Network Interfaces. Additional info:
Refresh host capabilities needs to be called manually now to assign the ip address to the newly attached interface
once setupNetworks is done, getCapabilities is called before the DHCP response that assigns IP address to interface.. The next call of getCapabilities then returns the IP address correctly. supervdsm.log --> MainProcess|Thread-15::INFO::2015-05-13 15:22:23,660::netconfpersistence::120::root::(save) Saved new config RunningConfig({'ovirtmgmt' : {u'blockingdhcp': True, u'nic': u'eth0', u'mtu': u'1500', u'bootproto': u'dhcp', u'STP': u'no', u'bridged': u'true'}, 'glusternw': {' nic': 'eth1', 'bootproto': 'dhcp', 'bridged': 'false', 'mtu': '1500'}}, {}) to /var/run/vdsm/netconf/nets/ and /var/run/vdsm/netconf/bo nds/ MainProcess|Thread-15::DEBUG::2015-05-13 15:22:23,661::supervdsmServer::112::SuperVdsm.ServerCallback::(wrapper) return setupNetworks w ith None sourceRoute::DEBUG::2015-05-13 15:22:25,102::sourceroutethread::38::root::(process_IN_CLOSE_WRITE_filePath) Responding to DHCP response in /var/run/vdsm/sourceRoutes/1431510745 vdsm.log --> Thread-15::DEBUG::2015-05-13 15:22:23,661::BindingXMLRPC::1164::vds::(wrapper) return setupNetworks with {'status': {'message': 'Done', 'code': 0}} Thread-16::DEBUG::2015-05-13 15:22:23,949::BindingXMLRPC::1157::vds::(wrapper) client [10.3.226.21]::call ping with () {} flowID [68df2 dfb] Thread-16::DEBUG::2015-05-13 15:22:23,949::BindingXMLRPC::1164::vds::(wrapper) return ping with {'status': {'message': 'Done', 'code': 0}} Thread-16::DEBUG::2015-05-13 15:22:24,509::BindingXMLRPC::1157::vds::(wrapper) client [10.3.226.21]::call getCapabilities with () {} fl owID [68df2dfb] Thread-16::DEBUG::2015-05-13 15:22:24,721::BindingXMLRPC::1164::vds::(wrapper) return getCapabilities with {'status': {'message': 'Done', 'code': 0}, 'info': {'HBAInventory': {'iSCSI': [{'InitiatorName': 'iqn.1994-05.com.redhat:9489407a6cea'}], .... supportedProtocols': ['2.2', '2.3'], 'networks': {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': '10.70.43.181', 'cfg': {'IPV6INIT': 'no', 'DEFROUTE': 'yes', 'HOTPLUG': 'no', 'MTU': '1500', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'STP': 'off', 'DEVICE': ' ovirtmgmt', 'TYPE': 'Bridge', 'ONBOOT': 'yes'}, 'bridged': True, 'ipv6addrs': ['2620:52:0:4628:215:1eff:fe00:6c4e/64', 'fe80::215:1eff: fe00:6c4e/64'], 'gateway': '10.70.43.254', 'dhcpv4': True, 'netmask': '255.255.252.0', 'dhcpv6': False, 'stp': 'off', 'ipv4addrs': ['10 .70.43.181/22'], 'mtu': '1500', 'ipv6gateway': 'fe80:52:0:4628::1fe', 'ports': ['eth0']}, 'glusternw': {'iface': 'eth1', 'addr': '', 'b ridged': False, 'ipv6addrs': ['fe80::215:1eff:fe00:2487/64'], 'mtu': '1500', 'dhcpv4': True, 'netmask': '', 'dhcpv6': False, 'ipv4addrs ': [], 'interface': 'eth1', 'ipv6gateway': '::', 'gateway': ''}},
Dan, is this expected behaviour that Refresh Capabilities has to be done manually after a logical network is assigned to an interface?
No, this is not the desired behaviour. However, we do know that it can happen when the dhcp server is slow. Basically, it is a race between dhcp server providing an address and Engine asking about it. If this is indeed the case, its solution would come up when events are integrated into vdsm/Engine API. Them, Vdsm could inform Engine of newly supplied address. Could you verify that there is no such problem with static addresses? There is still a chance we can provide these events in 3.6; I'll keep this BZ open to track this issue.
When i assign the static ip address from the set up Host Networks tab it comes up quickly i.e with out performing refresh capabilities on the host. But if there are any modifications done from the CLI then i have to run refresh capabilities on that host to get the address.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
*** This bug has been marked as a duplicate of bug 1240719 ***