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


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.


vdsm-devel mailing list

Reply via email to