Description of problem: When one or more storage node is down in cluster, disabling shared storage deletes shared storage volume, however when storage node comes up, shared storage volume is created again and Cluster.enable-shared-storage is disabled. Which will mislead the user. Version-Release number of selected component (if applicable): [root@darkknight ~]# rpm -qa | grep glusterfs glusterfs-libs-3.7.1-14.el7rhgs.x86_64 glusterfs-fuse-3.7.1-14.el7rhgs.x86_64 glusterfs-3.7.1-14.el7rhgs.x86_64 glusterfs-api-3.7.1-14.el7rhgs.x86_64 glusterfs-cli-3.7.1-14.el7rhgs.x86_64 glusterfs-geo-replication-3.7.1-14.el7rhgs.x86_64 glusterfs-client-xlators-3.7.1-14.el7rhgs.x86_64 glusterfs-server-3.7.1-14.el7rhgs.x86_64 How reproducible: 100% Steps to Reproduce: 1. Create shared storage e.g gluster volume set all cluster.enable-shared-storage disable 2. bring down one or two storage nodes, which hosts shared storage bricks 3. disable shared storage e.g gluster volume set all cluster.enable-shared-storage disable 4. Bring up the the storage nodes Actual results: When storage nodes comes up, Shared storage volume is created again and gluster volume info shows cluster.enable-shared-storage disable. Expected results: TBD Additional info:
This is an existing architecture problem with Glusterd. If volume is deleted when nodes are down then this scenario could occur. This problem will be addressed in Gluterd 2.0. Therefore we are not planning to address this in the current release. Some aspect of this bug is been addressed in the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=1291262