[Engine-devel] ovirt-host-deploy and multible bridges

[Sahina Bose]

Decoding "correct address"  - glusterHostsList should return any 
ipAddress that engine knows as being associated with host.
It could be either ipAddress used while adding host (stored as hostname 
in vds_static) or any of the ipAddresses populated in vds_interface 
table (addr column) .
I do not have enough knowledge about this bit of code to say what 
entries are made in vds_interface table. I know there's an entry for 
ovirtmgmt here but not sure if this gets added as part of addHost flow 
or not.

thx
sahina

On 04/09/2013 06:05 PM, Dan Kenigsberg wrote:
> On Tue, Apr 09, 2013 at 03:55:25PM +0530, Sahina Bose wrote:
>> [Adding vdsm-devel]
>>
>> On 04/09/2013 03:40 PM, Sahina Bose wrote:
>>> Hi all,
>>>
>>> I'm testing the bootstrapping of host without reboot on Fedora 18. After
>>> host's bootstrap,
>>> Ifconfig output returns this:
>>>
>>> ovirtmgmt: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>>>           inet 10.70.37.219  netmask 255.255.254.0  broadcast 10.70.37.255
>>>     <snipped>
>>>
>>> virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
>>>           inet 192.168.122.1  netmask 255.255.255.0  broadcast
>>> 192.168.122.255
>>>          <snipped>
>>>
>>> Running*glusterHostsList*  vdsm verb, returns the ip address
>>> 192.168.122.1, whereas my host has been added with ip address 10.70.37.219
>>>
>>> If I reboot the host, the virbr0 bridge is removed, and there's no issue.
>>>
>>> The vdsm verb glusterHostsList - returns ipAddress of host +
>>> output of gluster peer probe. This is needed because a periodic
>>> sync job needs to make sure that the hosts added in engine are in
>>> sync with the gluster cli (hosts could also be added/removed from
>>> gluster cli).
>>>
>>> How can we make sure glusterHostsList picks the correct ipAddress?
> Can you define (in plain English) what is the "correct" address?
> The host may have multiple valid addresses (storage, migration, display,
> whatnot).
>
> Only when it's clear to us, we can start expressing this in Python.
>
>>> Reading the inetinfo based on bridge has been vetoed as we are
>>> doing away with bridges.
>>>
>>> It would also work if virbr0 was updated in vds_interfaces table.
>>> Since this is not happening either - we have an issue.
> It might be a valid hack to drop this default virbr0 on vdsm start - not
> only the libvirt definition thereof, but also the running kernel device.
>
> However, as expressed above, this would not solve your problem when you
> have a currently-running host with multiple addresses.
>
> Dan.