Bug 1031920 - glusterd: peer probe of local host returns success with message that it is not needed
glusterd: peer probe of local host returns success with message that it is no...
Status: CLOSED EOL
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: glusterd (Show other bugs)
2.1
x86_64 Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Gaurav Kumar Garg
SATHEESARAN
glusterd
:
Depends On:
Blocks: 1167714
  Show dependency treegraph
 
Reported: 2013-11-19 01:52 EST by Rahul Hinduja
Modified: 2016-06-05 19:38 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1167714 (view as bug list)
Environment:
Last Closed: 2015-12-03 12:13:07 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rahul Hinduja 2013-11-19 01:52:48 EST
Description of problem:
=======================

When probing a local host, the message return is "peer probe: success. Probe on localhost not needed". 

[root@dj ~]# gluster peer probe dj
peer probe: success. Probe on localhost not needed
[root@dj ~]# echo $?
0
[root@dj ~]# 
[root@dj ~]# gluster peer status
Number of Peers: 0
[root@dj ~]# 

If you notice the output of gluster peer probe dj, it says that probe is not needed but still it is success. If it's a success than it should print in the peer status, which obviously is not the intention. Logging can be enhanced as

"peer probe: failed. Probe on localhost not needed" OR,
"peer probe: Probe on localhost not needed"



Version-Release number of selected component (if applicable):
=============================================================

glusterfs-3.4.0.44rhs-1.el6rhs.x86_64


How reproducible:
=================
1/1


Steps to Reproduce:
1. probe a local host using "gluster peer probe <local-host>

Actual results:
===============
# gluster peer probe <local-host>
peer probe: success. Probe on localhost not needed

Expected results:
=================

# gluster peer probe <local-host>
peer probe: failed. Probe on localhost not needed

Or,

# gluster peer probe <local-host>
peer probe: Probe on localhost not needed


Additional info:
Comment 2 SATHEESARAN 2014-11-24 09:20:06 EST
When the host which already part of the cluster is probed again, the same anomaly is seen.

[root@dhcp37-44 ~]# gluster peer status
Number of Peers: 2

Hostname: dhcp37-201.lab.eng.blr.redhat.com
Uuid: 96527a4d-4a99-4a84-9a45-7a2b6f062601
State: Peer in Cluster (Connected)

Hostname: dhcp37-216.lab.eng.blr.redhat.com
Uuid: 7ebe68dc-8c81-4475-bbd0-102c8686b576
State: Peer in Cluster (Connected)


[root@dhcp37-44 ~]# gluster peer probe dhcp37-201.lab.eng.blr.redhat.com
peer probe: success. Host dhcp37-201.lab.eng.blr.redhat.com port 24007 already in peer list

[root@dhcp37-44 ~]# echo $?
0

Even in this case, the cli response says "Peer Probe Success" and there is warning message, and response return value is 0 - which means success.

Expected Result:
There should not be the response saying ; "peer probe: success" and return value should not be 0 - in this case
Comment 3 Kaushal 2014-12-18 02:27:08 EST
Rahul, Sas,

Do you have any particular use case where this behaviour is not expected?
All the usecases I can think of with respect to peer probe only depend on the status of the probed peer after the command. You'd do one thing if the peer is not a member, or something else if it is.

Also, RHS-C team says they are currently dependent on this behaviour for something.

Gaurav already has a patch that changes the behaviour. But I don't want to accept it, as I don't believe it is required. I will only accept it if we can come up with a suitable case.

~kaushal
Comment 4 Rahul Hinduja 2014-12-18 04:39:05 EST
The only use case is the usability point of view of an end customer. A gluster peer command returns success where as no peer in the list. 

Since, RHS-C team is currently dependent on this behaviour and this is one of the rare case to hit/observe any way, I am ok to not take the patch now.

~Rahul
Comment 5 Vivek Agarwal 2015-12-03 12:13:07 EST
Thank you for submitting this issue for consideration in Red Hat Gluster Storage. The release for which you requested us to review, is now End of Life. Please See https://access.redhat.com/support/policy/updates/rhs/

If you can reproduce this bug against a currently maintained version of Red Hat Gluster Storage, please feel free to file a new report against the current release.

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