Bug 1065619 - gluster peer probe on localhost should fail with appropriate return value
Summary: gluster peer probe on localhost should fail with appropriate return value
Keywords:
Status: CLOSED DUPLICATE of bug 1167714
Alias: None
Product: GlusterFS
Classification: Community
Component: cli
Version: pre-release
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1244098
TreeView+ depends on / blocked
 
Reported: 2014-02-15 07:30 UTC by ssamanta
Modified: 2015-07-17 13:26 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1244098 (view as bug list)
Environment:
Last Closed: 2015-07-17 13:26:23 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description ssamanta 2014-02-15 07:30:56 UTC
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 /]#

Comment 1 ssamanta 2014-02-15 07:35:07 UTC
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 /]#

Comment 2 SATHEESARAN 2014-02-15 08:52:35 UTC
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

Comment 4 Manikandan 2015-07-14 13:13:30 UTC
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"

Comment 5 SATHEESARAN 2015-07-15 02:51:21 UTC
(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

Comment 6 Gaurav Kumar Garg 2015-07-17 13:26:23 UTC

*** This bug has been marked as a duplicate of bug 1167714 ***


Note You need to log in before you can comment on or make changes to this bug.