+++ This bug was initially created as a clone of Bug #1325831 +++

+++ This bug was initially created as a clone of Bug #1325821 +++

Description of problem:
gluster snap status xml output shows incorrect details when the snapshots are in deactivated state

Version-Release number of selected component (if applicable):
glusterfs-server-3.7.9-1.el7rhgs.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Create a snapshot
2. Run "gluster snap status --xml"

Actual results:
gluster snap status xml output shows incorrect details

Expected results:
gluster snap status xml output should show correct information

Additional info:

CLI Output:

[root@node94 ~]# gluster snap status snap1

Snap Name : snap1
Snap UUID : a322d93a-2732-447d-ab88-b943fa402fd2

	Brick Path        :   10.70.47.11:/run/gluster/snaps/2c790e6132e447e79168d9708d4abfe7/brick1/testvol_brick0
	Volume Group      :   RHS_vg0
	Brick Running     :   No
	Brick PID         :   N/A
	Data Percentage   :   3.52
	LV Size           :   9.95g


	Brick Path        :   10.70.47.16:/run/gluster/snaps/2c790e6132e447e79168d9708d4abfe7/brick2/testvol_brick1
	Volume Group      :   RHS_vg0
	Brick Running     :   No
	Brick PID         :   N/A
	Data Percentage   :   3.52
	LV Size           :   9.95g


	Brick Path        :   10.70.47.152:/run/gluster/snaps/2c790e6132e447e79168d9708d4abfe7/brick3/testvol_brick2
	Volume Group      :   RHS_vg0
	Brick Running     :   No
	Brick PID         :   N/A
	Data Percentage   :   3.51
	LV Size           :   9.95g


	Brick Path        :   10.70.46.52:/run/gluster/snaps/2c790e6132e447e79168d9708d4abfe7/brick4/testvol_brick3
	Volume Group      :   RHS_vg0
	Brick Running     :   No
	Brick PID         :   N/A
	Data Percentage   :   3.54
	LV Size           :   9.95g

Xml Output:

[root@node94 ~]# gluster snap status --xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cliOutput>
  <opRet>0</opRet>
  <opErrno>0</opErrno>
  <opErrstr/>
  <snapStatus>
    <snapshots>
      <snapshot>
        <name>snap1</name>
        <uuid>a322d93a-2732-447d-ab88-b943fa402fd2</uuid>
        <volCount>1</volCount>
        <volume>
          <brickCount>4</brickCount>
          <brick>
            <path>10.70.47.11:/run/gluster/snaps/2c790e6132e447e79168d9708d4abfe7/brick1/testvol_brick0</path>
            <volumeGroup>RHS_vg0</volumeGroup>
          </brick>
        </volume>
      </snapshot>
    </snapshots>
  </snapStatus>
</cliOutput>

--- Additional comment from Vijay Bellur on 2016-04-18 04:42:53 EDT ---

REVIEW: http://review.gluster.org/14018 (snapshot/cli: Fix snapshot status xml output) posted (#1) for review on master by Avra Sengupta (asengupt)

--- Additional comment from Vijay Bellur on 2016-08-18 03:14:19 EDT ---

REVIEW: http://review.gluster.org/14018 (snapshot/cli: Fix snapshot status xml output) posted (#2) for review on master by Avra Sengupta (asengupt)

--- Additional comment from Worker Ant on 2016-08-23 03:11:58 EDT ---

COMMIT: http://review.gluster.org/14018 committed in master by Rajesh Joseph (rjoseph) 
------
commit efbae0fef5399a8826782b02140f44edaea0dac3
Author: Avra Sengupta <asengupt>
Date:   Tue Apr 12 12:26:54 2016 +0530

    snapshot/cli: Fix snapshot status xml output
    
    snap status --xml errors out if a brick is down and
    doesn't have pid. It is handled in the cli of the snap
    status where "N/A" is displayed in such a scenario.
    Handled the same in xml
    
    snap status <snapname> --xml fails as the writer is
    not initialised for the same. Using GF_SNAP_STATUS_TYPE_ITER
    instead of GF_SNAP_STATUS_TYPE_SNAP for all snap's
    status to differentiate between the two scenarios.
    
    Added testcase volume-snapshot-xml.t to check
    all snapshot commands xml outputs
    
    Change-Id: I99563e8f3e84f1aaeabd865326bb825c44f5c745
    BUG: 1325831
    Signed-off-by: Avra Sengupta <asengupt>
    Reviewed-on: http://review.gluster.org/14018
    Smoke: Gluster Build System <jenkins.org>
    CentOS-regression: Gluster Build System <jenkins.org>
    NetBSD-regression: NetBSD Build System <jenkins.org>
    Reviewed-by: Rajesh Joseph <rjoseph>