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:
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
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
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
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.