Bug 1031920

Summary:	glusterd: peer probe of local host returns success with message that it is not needed
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	Rahul Hinduja <rhinduja>
Component:	glusterd	Assignee:	Gaurav Kumar Garg <ggarg>
Status:	CLOSED EOL	QA Contact:	SATHEESARAN <sasundar>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	2.1	CC:	ggarg, kaushal, rhinduja, sasundar, smohan, vbellur
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Unspecified
Whiteboard:	glusterd
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1167714 (view as bug list)		Environment:
Last Closed:	2015-12-03 17:13:07 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1167714

Description Rahul Hinduja 2013-11-19 06:52:48 UTC

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 14:20:06 UTC

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 07:27:08 UTC

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 09:39:05 UTC

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 17:13:07 UTC

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.