Bug 1467841 - gluster volume status --xml fails when there are 100 volumes
gluster volume status --xml fails when there are 100 volumes
Product: GlusterFS
Classification: Community
Component: cli (Show other bugs)
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Atin Mukherjee
: Triaged
Depends On:
Blocks: 1467807 1470488 1470495
  Show dependency treegraph
Reported: 2017-07-05 06:03 EDT by Atin Mukherjee
Modified: 2017-10-26 10:35 EDT (History)
9 users (show)

See Also:
Fixed In Version: glusterfs-3.12.0
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1467807
: 1470488 (view as bug list)
Last Closed: 2017-09-05 13:35:44 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Comment 1 Atin Mukherjee 2017-07-05 06:08:04 EDT
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):


How reproducible:


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 $?

Command fails without giving proper xml

Expected results:

gluster v status --xml  should xml output of command
Comment 2 Worker Ant 2017-07-05 06:08:57 EDT
REVIEW: https://review.gluster.org/17702 (cli/xml: fix return handling) posted (#1) for review on master by Atin Mukherjee (amukherj@redhat.com)
Comment 3 Worker Ant 2017-07-06 05:46:24 EDT
COMMIT: https://review.gluster.org/17702 committed in master by Atin Mukherjee (amukherj@redhat.com) 
commit c7efdb834772ddd8f6b07214d3eb2d26425cb79b
Author: Atin Mukherjee <amukherj@redhat.com>
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.
    Change-Id: I02ee7076e1d8c26cf654d3dc3e77b1eb17cbdab0
    BUG: 1467841
    Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
    Reviewed-on: https://review.gluster.org/17702
    Smoke: Gluster Build System <jenkins@build.gluster.org>
    Reviewed-by: Amar Tumballi <amarts@redhat.com>
    CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
    Reviewed-by: Gaurav Yadav <gyadav@redhat.com>
Comment 4 hansmi 2017-07-12 07:04:26 EDT
Atin, I encountered this very issue on a Gluster 3.10.3 cluster in production and can see the problematic code in 3.8 too. Could you please backport this fix?
Comment 5 hansmi 2017-07-12 07:06:50 EDT
What I forgot to mention is that the cluster in question has only 16 volumes:

# gluster volume list | wc -l

The failing command is "gluster --mode=script --xml volume status all".
Comment 6 Shyamsundar 2017-09-05 13:35:44 EDT
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.12.0, please open a new bug report.

glusterfs-3.12.0 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-September/000082.html
[2] https://www.gluster.org/pipermail/gluster-users/

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