After a very unfortunate AC incident I had to shutdown my home systems for about a week attempting to make conditions bareable. Unfortunately Gluster did not come back online healthy. It took me a while to figure out the devices contianing bricks were not connected due to an IP address change. Despite this happening a while ago some layers of Gluster were successful in establishing a connection. I am not sure if this an artifact of running version 6, the default in Ubuntu or another reason.

Regardless I would prefer not to SSH into each box and run a series of commands or edit files. Something Gluster docs love to advocate. In order to get a decent overview I’ve decided to build a client. There are no packaged libraries to really control Gluster except through the command line. I am thankful the CLI will at least generate XML however this feels extremely antiquated. This itself might drive me to setup a Gluster cluster with block storage, or try Cephfs instead.

So far the peer status operation produces XML like:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <stateStr>Peer in Cluster</stateStr>

The xml2js library is at least decent at parsing the output. As this matures there are stream parsing options which may make more sense. Pretty straight forward to consume and interpolate. Looks like a viable path going forward.

From an operational standpoint building against Gluster is a risk. To use the CLI you must run as root or otherwise figure out the poorly documented capability of running under a specific group. As such I am really close to abandoning the approach of using Gluster. This may just be wavering feelings after trying to restore the cluster. Perhaps just I should just consider the block approach? The downside of that is recovery. Using the filesystem brick type allows me to recover files when something fails.