+++ This bug was initially created as a clone of Bug #845509 +++ gluster volume stop --xml outputs <cliOutput> <volStop> <flags>0</flags> <volname>test1</volname> </volStop> </cliOutput> excepted xml is <cliOutput> <opRet>0</opRet> <opErrno>0</opErrno> <opErrstr/> <volStop> <volume> <name>music</name> <id>b3114c71-741b-4c6f-a39e-80384c4ea3cf</id> <status>1</status> </volume> </volStop> </cliOutput>
Patch for upstream/master under review at http://review.gluster.org/3869
Fixed by commit f1f3d1c (cli: Changes and enhancements to XML output) for bug https://bugzilla.redhat.com/show_bug.cgi?id=828131 . Reviewed at http://review.gluster.org/3869 .
Not yet fixed in version glusterfs 3.3.0rhsvirt1-8.el6rhs, Moving to ASSIGNED
fixed only in upstream... available to testing with 3.4.0qa2 release.
verified on glusterfs 3.4.0qa5 not working as per excepted xml mentioned above so changing status actual output gluster volume stop test --xml Stopping volume will make its data inaccessible. Do you want to continue? (y/n) y <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <cliOutput><opRet>0</opRet><opErrno>115</opErrno><opErrstr></opErrstr><volStop><volume><name>test</name><id>fc58bdfa-d7f4-41bf-b829-5bf8f35713fb</id></volume></volStop></cliOutput> expected below xml data is missing:- <status>1</status> below xml data is not structured properly:- <opErrstr></opErrstr>
The fix for this under review here http://review.gluster.org/4355
verified on 3.4.0.2rhs-1.el6rhs.x86_64 1. moving back to assigned below xml data is missing:- <status>1</status> e.g. [root@cutlass ~]# gluster volume stop 22 --xml Stopping volume will make its data inaccessible. Do you want to continue? (y/n) y <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <cliOutput> <opRet>0</opRet> <opErrno>115</opErrno> <opErrstr/> <volStop> <volume> <name>22</name> <id>fc487e35-179f-49c3-91c5-efdce5525dea</id> </volume> </volStop> </cliOutput> 2. need info a) <opErrno> is always 115. Is this expected behaviour? b) In case of failure, <volStop> and all tags under it are not displayed. Is this expected behaviour? e.g. [root@cutlass ~]# gluster volume stop 22 --xml Stopping volume will make its data inaccessible. Do you want to continue? (y/n) y <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <cliOutput> <opRet>-1</opRet> <opErrno>115</opErrno> <opErrstr>Volume 22 is not in the started state</opErrstr> </cliOutput>
Regarding the tags not being shown during error, that is expected. And I believe that's good enough for RHSC team, which is the primary user for xml outputs. Anyway, tagging this as a needinfo from Bala. Bala, Can you give your opinions? Other than that, I'll take a look into the other errors. Reducing priority, as I this isn't something serious. - Kaushal
Current xml output resolves this issue. I would prefer this bz to be closed safely.
verified with 3.4.0.52rhs-1.el6rhs.x86_64 But unable to understand <opErrno> tag. In case of failure it is always zero and on success it has different number each time. e.g. [root@7-VM1 ~]# gluster volume stop xml12 --xml Stopping volume will make its data inaccessible. Do you want to continue? (y/n) y <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <cliOutput> <opRet>0</opRet> <opErrno>2</opErrno> <opErrstr/> <volStop> <volume> <name>xml12</name> <id>1a0f073a-d508-4899-9b90-90ef7d6b2ebc</id> </volume> </volStop> </cliOutput> [root@7-VM1 ~]# gluster volume stop xml1 --xml Stopping volume will make its data inaccessible. Do you want to continue? (y/n) y <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <cliOutput> <opRet>0</opRet> <opErrno>13</opErrno> <opErrstr/> <volStop> <volume> <name>xml1</name> <id>fa685aab-02c9-4c73-9ffc-275bd1df0db7</id> </volume> </volStop> </cliOutput> Could you please explain use of this tag and behaviour mentioned above is expected or not? What is expected value for that tag in case of failure and success.
moving this bug to verified as xml output format is proper and opening new bug/RFE for this <opErrno> tag
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2014-0208.html