Bug 1214636

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 ***