Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1162095

Summary:	gstatus: gstatus fails if the glusterd on local machine is not running.
Product:	[Community] GlusterFS	Reporter:	Sachidananda Urs <surs>
Component:	unclassified	Assignee:	Paul Cuzner <pcuzner>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	mainline	CC:	bugs, ndevos, surs
Target Milestone:	---	Keywords:	FutureFeature, Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-08-29 03:54:06 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:

Description Sachidananda Urs 2014-11-10 09:23:00 UTC

Description of problem:

gstatus fails to work if glusterd on the local machine is down.

[root@guido ~]# gstatus
 
gluster did not respond to a peer status request, gstatus
can not continue.

[root@guido ~]# 

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

gstatus 0.62

How reproducible:

Always.


Steps to Reproduce:
1. service glusterd stop or pkill glusterd 
2. gstatus

Comment 1 Niels de Vos 2014-11-11 12:43:44 UTC

I think this is rather expected and gstatus gives a sensible error message?

Sac, could you explain a little what your expectations are?

Thanks!

Comment 2 Sachidananda Urs 2014-11-12 07:39:25 UTC

Neils, I was wondering if gstatus could talk to any of the glusterd that is alive and could give status of the cluster.

For example:

When one of the other nodes other than the local node is down, gstatus shows nodes and bricks as 3/4. However when the local node is gone, it just fails.

I don't know how gstatus communicates to glusterd, I haven't seen the code. So, I'm not quite aware of the complexity or limitation here.

Comment 3 Niels de Vos 2014-11-12 08:19:14 UTC

Thanks, that is a request that I think is doable. I do not really know how gstatus works internally, but if it only communicates with glusterd through the gluster-cli, the other peers in the trusted pool could be tried. The peers are listed by hostname or IP in /var/lib/glusterd/peers/ and it is possible to call "gluster --remote-host=$OTHER_PEER ...".

But well, it's up to Paul to judge if this is could work and is acceptable.

Comment 4 Paul Cuzner 2014-11-13 06:21:11 UTC

Yep - that could work. Everything gstatus does is through the CLI and where available interpreting the XML output. When gstatus starts up it creates some node objects, so there is a potential of pushing the CLI interaction to a separate class based on one of the nodes that have been detected (I was going to do this anyway, since I want to add a CLI timeout)

A quick check shows that all but one of the commands used in gstatus would work with a --remote-host...here's the 'problem child'

[root@rhs3-2 ~]# gluster --remote-host=rhs3-1 vol heal admin info 
admin: Not able to fetch volfile from glusterd
Volume heal failed

By default I don't run the heal command since it's slow, so if the user requests the heal data and the local node is down gstatus could just terminate early with an error that says that data isn't available since the local glusterd is down..

Thoughts?

Comment 5 Sachidananda Urs 2014-11-13 07:12:19 UTC

Thats a good idea.
Also, if the files that need to be healed are in millions, it will be too clumsy to do it. So, I suggest we leave the heal and related commands to gluster.
Or maybe you can just get the number of files that need to be healed and report them, but not the entire list of files.

Comment 6 Amar Tumballi 2018-08-29 03:54:06 UTC

Lot of time since no activity on this bug. We have either fixed it already or it is mostly not critical anymore!

Please re-open the bug if the issue is burning for you, or you want to take the bug to closure with fixes.