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

[Dan Kenigsberg]

On Wed, Apr 10, 2013 at 02:23:14PM +0530, 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.


And what about these ^^^ ?
Is there any reason to keep these guesses elsewhere in the code?