Description of problem: # gluster volume status does not display bricks on nodes where glusterd is not running. Is it possible for gluster to display the bricks, even in an offline state, so that all bricks are visible? How reproducible: At all times Steps to Reproduce: 1. Given a TSP with all nodes operational and gluster volume status showing all bricks online 2. Stop glusterd on any node then repeat gluster volume status 3. Bricks on the node that has had glusterd stopped will no longer appear Actual results: Bricks don't show up at all when the glusterd daemon on the node isn't running Expected results: Bricks should show up in an offline state if glusterd is not running on a node
(In reply to Cal Calhoun from comment #0) > Description of problem: > # gluster volume status does not display bricks on nodes where glusterd is > not running. Is it possible for gluster to display the bricks, even in an > offline state, so that all bricks are visible? > > How reproducible: > At all times > > Steps to Reproduce: > 1. Given a TSP with all nodes operational and gluster volume status showing > all bricks online > 2. Stop glusterd on any node then repeat gluster volume status > 3. Bricks on the node that has had glusterd stopped will no longer appear > > Actual results: > Bricks don't show up at all when the glusterd daemon on the node isn't > running > > Expected results: > Bricks should show up in an offline state if glusterd is not running on a > node The expected result put up here is wrong. We can't show a brick as offline if the respective node's glusterd service is only down. As per GlusterD design, when volume status is issued, individual glusterds running on the nodes have to report back the status of the respective brick processes and other daemons. If a particular glusterd instance of a node (say N2) is down and a volume status command was issued on N1, glusterd instance of N1 can not communicate to glusterd instance of N2 because of which in the volume status output N2's information is not shown up. At max, we could report back the status of N2's daemon status as not available but would that serve the purpose, I guess no? With GlusterD 2.0's design this might be solved if the daemon status information is stored in central store i.e. etcd.
(In reply to Atin Mukherjee from comment #2) > (In reply to Cal Calhoun from comment #0) > > Description of problem: > > # gluster volume status does not display bricks on nodes where glusterd is > > not running. Is it possible for gluster to display the bricks, even in an > > offline state, so that all bricks are visible? > > > > How reproducible: > > At all times > > > > Steps to Reproduce: > > 1. Given a TSP with all nodes operational and gluster volume status showing > > all bricks online > > 2. Stop glusterd on any node then repeat gluster volume status > > 3. Bricks on the node that has had glusterd stopped will no longer appear > > > > Actual results: > > Bricks don't show up at all when the glusterd daemon on the node isn't > > running > > > > Expected results: > > Bricks should show up in an offline state if glusterd is not running on a > > node > > The expected result put up here is wrong. We can't show a brick as offline > if the respective node's glusterd service is only down. As per GlusterD > design, when volume status is issued, individual glusterds running on the > nodes have to report back the status of the respective brick processes and > other daemons. If a particular glusterd instance of a node (say N2) is down > and a volume status command was issued on N1, glusterd instance of N1 can > not communicate to glusterd instance of N2 because of which in the volume > status output N2's information is not shown up. At max, we could report back > the status of N2's daemon status as not available but would that serve the > purpose, I guess no? > > With GlusterD 2.0's design this might be solved if the daemon status > information is stored in central store i.e. etcd. Thanks Atin. I get the logic. I'm assuming that, without N2's glusterd responding, N1 doesn't know about N2's bricks at all and that implementing it within the current glusterd framework would be prohibitively expensive? Is this something that's on the radar at all for GlusterD 2.0?
github issue https://github.com/gluster/glusterd2/issues/325 is filed to track this change under GlusterD 2.0 project upstream.