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

[Sahina Bose]

On 04/10/2013 02:19 PM, Balamurugan Arumugam wrote:
> On 04/10/2013 11:18 AM, Sahina Bose wrote:
>>
>> On 04/10/2013 12:25 AM, Dan Kenigsberg wrote:
>>> On Tue, Apr 09, 2013 at 07:28:17PM +0530, Balamurugan Arumugam wrote:
>>>> On 04/09/2013 06:37 PM, Sahina Bose wrote:
>>>>> 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.
>>>>>
>>>> I guess, vds_interface table is populated by ips given by vdsm
>>>> through getVdsCaps.
>>>>
>>>> Current glusterHostsList provides one of ipaddress of the local host
>>>> (other than 127.*.*.*).   If virbr0 is enabled, it picks up
>>>> 192.168.122.1 ip address of the bridge and sends to the engine, but
>>>> this entry is missing in the table.
>>>>
>>>> The requirement is that we need a ip of the local host which is also
>>>> stored in the database.
>>>>
>>>> The database has entries of ips of a host those are from physical
>>>> nics and/or bridges who has slaves to nics.
>>> It's not something I've tested, or want to encourage, but currently,
>>> outside of gluster, Vdsm may run behind a fancy NAT as a virtual 
>>> server.
>>> I.e., its local undress may be utterly different from the address used
>>> by Engine.
>>>
>>> I'd like to keep having this flexibility, and not to assume otherwise.
>>>
>>> Why does glusterHostsList need to return the ip of the management
>>> network? The client that issued this verb has to know that IP in the
>>> first place.
>>>
>>> I notice that the idiom "_getLocalIpAddress() or _getGlusterHostName()"
>>> is used all too often in vdsm/gluster/cli.py.
>>>
>>> How about changing the Vdsm/Engine API so that the string 
>>> "localhost" is
>>> returned instead? Then, Engine can replace it with whatever it seems
>>> fit.
>>>
>>> Dan.
>> Dan,
>>
>> Thanks for clarifying. Looks like relying on the IpAddress to determine
>> the host will be prone to errors going forward.
>> We will change the approach and start using the UUID that gluster peer
>> status returns to identify host - will create a new verb glusterPeerList
>> that does this.
>>
>
> Current glusterHostsList provides list of
> {'hostname': HOSTNAME, 'uuid': UUID, 'status': STATE} including local 
> host.
>
> What will be the difference between new glusterPeerList and existing 
> glusterHostsList?
>
If this is the case, we just need to make sure at engine we use UUID and 
not IP address to identify host. We would still need a vdsm verb that 
will return the current host gluster UUID, to store in engine in case of 
Add Host flow.
>
>
>> And for the current host, like you mentioned, since the engine already
>> knows which vdsm host this command is executed on, the engine will not
>> rely on vdsm to return the host's IP.
>>
>
>
> Regards,
> Bala
>
>