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

[Dan Kenigsberg]

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.