Bug 1470488 - gluster volume status --xml fails when there are 100 volumes
gluster volume status --xml fails when there are 100 volumes
Status: CLOSED CURRENTRELEASE
Product: GlusterFS
Classification: Community
Component: cli (Show other bugs)
3.10
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Atin Mukherjee
: Triaged
Depends On: 1467841
Blocks: 1467807 1470495
  Show dependency treegraph
 
Reported: 2017-07-12 23:57 EDT by Atin Mukherjee
Modified: 2017-08-21 09:40 EDT (History)
8 users (show)

See Also:
Fixed In Version: glusterfs-3.10.5
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1467841
: 1470495 (view as bug list)
Environment:
Last Closed: 2017-08-21 09:40:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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-12 23:57:50 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):

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-12 23:58:36 EDT
REVIEW: https://review.gluster.org/17764 (cli/xml: fix return handling) posted (#1) for review on release-3.10 by Atin Mukherjee (amukherj@redhat.com)
Comment 3 Worker Ant 2017-07-19 17:31:59 EDT
COMMIT: https://review.gluster.org/17764 committed in release-3.10 by Raghavendra Talur (rtalur@redhat.com) 
------
commit 470889caeb67c8e5874f19867879104c9fc73a8f
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.
    
    >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>
    
    Change-Id: I02ee7076e1d8c26cf654d3dc3e77b1eb17cbdab0
    BUG: 1470488
    Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
    Reviewed-on: https://review.gluster.org/17764
    Smoke: Gluster Build System <jenkins@build.gluster.org>
    CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
    NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
    Reviewed-by: Raghavendra Talur <rtalur@redhat.com>
Comment 4 Shyamsundar 2017-08-21 09:40:58 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.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/

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