Bug 1470488

Summary:	gluster volume status --xml fails when there are 100 volumes
Product:	[Community] GlusterFS	Reporter:	Atin Mukherjee <amukherj>
Component:	cli	Assignee:	Atin Mukherjee <amukherj>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	3.10	CC:	amukherj, ashah, bugs, public, rhinduja, rhs-bugs, storage-qa-internal, vbellur
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	glusterfs-3.10.5	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1467841
Clones:	1470495 (view as bug list)		Environment:
Last Closed:	2017-08-21 13:40:58 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:	1467841
Bug Blocks:	1467807, 1470495

Comment 1 Atin Mukherjee 2017-07-13 03:57:50 UTC

Description of problem:

when there are large number of volumes in my case 100 volumes, gluster v status --xml command fails

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

mainline

How reproducible:

100%

Steps to Reproduce:
1. create & start 100 volume
2. execure gluster v status --xml

Actual results:

[root@dhcp46-22 ~]# gluster v status all clients --xml
[root@dhcp46-22 ~]# echo $?
92

Command fails without giving proper xml

Expected results:

gluster v status --xml  should xml output of command

Comment 2 Worker Ant 2017-07-13 03:58:36 UTC

REVIEW: https://review.gluster.org/17764 (cli/xml: fix return handling) posted (#1) for review on release-3.10 by Atin Mukherjee (amukherj)

Comment 3 Worker Ant 2017-07-19 21:31:59 UTC

COMMIT: https://review.gluster.org/17764 committed in release-3.10 by Raghavendra Talur (rtalur) 
------
commit 470889caeb67c8e5874f19867879104c9fc73a8f
Author: Atin Mukherjee <amukherj>
Date:   Wed Jul 5 14:58:50 2017 +0530

    cli/xml: fix return handling
    
    The return code of xmlTextWriter* APIs says it returns either the bytes
    written (may be 0 because of buffering) or -1 in case of error. Now if the
    volume of the xml data payload is not huge then most of the time the
    data to be written gets buffered, however when this grows sometimes this
    APIs will return the total number of bytes written and then it becomes
    absolutely mandatory that every such call is followed by
    XML_RET_CHECK_AND_GOTO otherwise we may end up returning a non zero ret
    code which would result into the overall xml generation to fail.
    
    >Reviewed-on: https://review.gluster.org/17702
    >Smoke: Gluster Build System <jenkins.org>
    >Reviewed-by: Amar Tumballi <amarts>
    >CentOS-regression: Gluster Build System <jenkins.org>
    >Reviewed-by: Gaurav Yadav <gyadav>
    
    Change-Id: I02ee7076e1d8c26cf654d3dc3e77b1eb17cbdab0
    BUG: 1470488
    Signed-off-by: Atin Mukherjee <amukherj>
    Reviewed-on: https://review.gluster.org/17764
    Smoke: Gluster Build System <jenkins.org>
    CentOS-regression: Gluster Build System <jenkins.org>
    NetBSD-regression: NetBSD Build System <jenkins.org>
    Reviewed-by: Raghavendra Talur <rtalur>

Comment 4 Shyamsundar 2017-08-21 13:40:58 UTC

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.10.5, please open a new bug report.

glusterfs-3.10.5 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://lists.gluster.org/pipermail/announce/2017-August/000079.html
[2] https://www.gluster.org/pipermail/gluster-users/