3.1: Multiple networks and Client access

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi and thanks for the answer.

I do not really know why it does not work. One problem seems to be how the server that is used for adding peers is added to the DB. Let me quote:

> > - when I add a peer with its internal name it works, except for the peer that I add the other peers from.
> > ---hostname2.internal: $ gluster peer probe hostname1.internal
> > ---hostname1.internal $ gluster peer status
> > Number of Peers: 1
> > 
> > Hostname: 10.10.33.142
> > Uuid: a19fc9d3-d00f-4440-b096-c974db1cd8c7
> > State: Peer in Cluster (Connected)
> > 
> > This should be hostname2.internal
> > 
> > When I do gluster peer probe hostname1.internal (on the host hostname1.internal) I get:
> > 
> > "hostname1.internal is already part of another cluster"
> > so here, ip/name resolution works...
> > 
> > this works in all permutations. The peer from which I do "gluster peer probe ..." always does not resolve to its internal name, but its ip-adress
> > 
> > As a result from all this, point a) can not succeed, since:
> > 
> > gluster volume create .... hostname... hostname... hostname... results in:
> > 
> > "Host hostnameX is not a friend", where hostnameX ist the host where the volume creation was attempted.
> > 

IF gluster would use the hostname for all peers, then I guess there would be no problem at all.

Do you have a bug number so I could track the state myself?

Thanks,
udo.

-- 
---[ Institute of Cognitive Science @ University of Osnabrueck
---[ Albrechtstrasse 28, D-49076 Osnabrueck, 969-3362
---[ Documentation: https://doc.ikw.uni-osnabrueck.de





[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux