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

[Balamurugan Arumugam]

On 04/10/2013 02:23 PM, Sahina Bose wrote:
>
> 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.


I think, getVdsCaps can include this.  Dan, is it good idea?


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