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

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?

> 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