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 _______________________________________________ Gluster-users mailing list Gluster-users@gluster.org http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
