Bug 1377302

+++ This bug was initially created as a clone of Bug #1246047 +++

+++ This bug was initially created as a clone of Bug #1214636 +++

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):
RHV 4.0
RHGS 3.1.3

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 comment from Sahina Bose on 2015-04-27 02:52:16 EDT ---

Refresh host capabilities needs to be called manually now to assign the ip address to the newly attached interface

--- Additional comment from Sahina Bose on 2015-05-13 07:13:36 EDT ---

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': ''}},

--- Additional comment from Sahina Bose on 2015-05-18 02:52:01 EDT ---

Dan, is this expected behaviour that Refresh Capabilities has to be done manually after a logical network is assigned to an interface?

--- Additional comment from Dan Kenigsberg on 2015-05-18 10:23:10 EDT ---

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.

--- Additional comment from RamaKasturi on 2015-05-19 08:27:57 EDT ---

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.