On Wed, Apr 10, 2013 at 02:27:55PM +0530, Balamurugan Arumugam wrote: > 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?
I do not mind adding glusterUUID to this "bag of things". (preferably impleneting it within the vdsm-gluster subpackage) I hope Saggi or Adam do not mind making getVdsCaps a little bit more dirty - they may sagguest that you add a getGlusterUUID verb. Dan. _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel