Description of problem: The gluster peer probe with the IPv6 link-local address gives confusing output Version-Release number of selected component (if applicable): [root@desktop8 /]# rpm -qa | grep glusterfs glusterfs-3.5.0-0.5.beta3.fc20.x86_64 glusterfs-cli-3.5.0-0.5.beta3.fc20.x86_64 glusterfs-libs-3.5.0-0.5.beta3.fc20.x86_64 glusterfs-server-3.5.0-0.5.beta3.fc20.x86_64 glusterfs-fuse-3.5.0-0.5.beta3.fc20.x86_64 [root@desktop8 /]# How reproducible: Steps to Reproduce: 1.Install the glusterfs 3.5 beta3 2.Create bricks with xfs partition and start the glustered service 3.run command "gluster peer probe <IPv6 link-local address> Actual results: peer probe: success. Probe on localhost not needed [root@desktop8 /]# gluster peer status Number of Peers: 0 Expected results: When the peer probe command succeeded but gluster peer status returned 0 Additional info: [root@desktop8 /]# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 90:b1:1c:7b:2d:02 brd ff:ff:ff:ff:ff:ff inet 192.168.0.8/24 brd 192.168.0.255 scope global dynamic em1 valid_lft 18037sec preferred_lft 18037sec inet6 fe80::92b1:1cff:fe7b:2d02/64 scope link valid_lft forever preferred_lft forever 3: p1p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 00:0a:f7:03:a7:9d brd ff:ff:ff:ff:ff:ff [root@desktop8 /]# gluster peer probe fe80::92b1:1cff:fe7b:2d02 peer probe: success. Probe on localhost not needed [root@desktop8 /]# gluster peer status Number of Peers: 0 [root@desktop8 /]# gluster peer probe 90:b1:1c:7b:2d:02 90:b1:1c:7b:2d:02 is an invalid address Usage: peer probe <HOSTNAME> [root@desktop8 /]# gluster peer status Number of Peers: 0 [root@desktop8 /]# gluster peer status Number of Peers: 0 [root@desktop8 /]# gluster peer probe fe80::92b1:1cff:fe7b:2d02 peer probe: success. Probe on localhost not needed [root@desktop8 /]# echo $? 0 [root@desktop8 /]#
The same thing happens with local IPv4 address as well. [root@desktop8 /]# gluster peer probe 192.168.0.8 peer probe: success. Probe on localhost not needed [root@desktop8 /]# gluster peer status Number of Peers: 0 [root@desktop8 /]#
This is not true with IPV6 addresses and it hols true for IPV4 too. The issue is when you probe a localhost, 1. The probe shows success and warning together 2. The return value is not appripriate So, changing the summary accordingly
Hi, By definition, a "peer" is not the system itself. It refers to the system in the same pool, but not itself. So, localhost will be always missing and it is the expected behaviour. Instead, one can use "gluster pool list" to see all the systems in the trusted pool"
(In reply to Manikandan from comment #4) > Hi, > By definition, a "peer" is not the system itself. It refers to the system in > the same pool, but not itself. So, localhost will be always missing and it > is the expected behaviour. > Instead, one can use "gluster pool list" to see all the systems in the > trusted pool" I agree that this is the expected behaviour. But if you look at it more closer, you can realize the problem. When a user tries to probe a same host ( say, by mistake ), gluster cli returns the error messages as follows : "peer probe: success. Probe on localhost not needed" Note: gluster cli says, 'peer probe success' When you check the return value. <snip> # echo $? 0 </snip> Note: return value 0 means success. Ideal expected behaviour should be : 1. When you probe a localhost, gluster cli should throw error message - "Probe on localhost not needed" 2. Return value should not be 0 With this information, I re-open this bug
*** This bug has been marked as a duplicate of bug 1167714 ***