Description of problem: Bootstrapping doesn't care to chkconfig-ing glusterd for the required run levels. Version-Release number of selected component (if applicable): RHS 2.1 - glusterfs-3.4.0.4rhs-1.el6rhs How reproducible: Always Steps to Reproduce: 1.Install RHS 2.1 on a VM, using "http" (i.e) using the key --location when using virt-install and do a minimum install. OR Manually do chkconfig of glusterd "off" on all run levels (i.e) chkconfig glusterd off 2. Add this RHS node to cluster ( gluster cluster ) 3. After bootstrapping is done and node is up, check for glusterd status in the RHS node Actual results: glusterd is not up Expected results: glusterd should be up and running, post bootstrapping Additional info:
Satheesh, can you please check if its fixed in 3.4.0.9rhs builds? there are couple of fixes for 'chkconfig' of glusterd in the spec file.
Checked on glusterfs*-3.4.0.14rhs-1.el6rhs.x86_64 , and FAILED to qualify. On adding Red Hat Storage (RHS) node, in which glusterd has been set to be not started up on boot (chkconfig glusterd off), to a 'Gluster Enabled Cluster' on RHEVM, the bootstrapping of the RHS node does not ensure that glusterd will be started up on boot, ie, 'chkconfig glusterd on' is not being run during bootstrapping. As a result 'peer probe' will not work on that RHS node, or to that RHS node, and therefore the RHS node will be set as non-responsive.
This is added in glusterfs.spec file again. Can we check this?
Checked on glusterfs-server-3.4.0.32rhs-1.el6rhs.x86_64 , and FAILED to qualify. The glusterfs-server-3.4.0.32rhs-1.el6rhs.x86_64 package on installation correctly sets the glusterd daemon to be started up on boot. But the reproducer for this BZ states to manually 'chkconfig glusterd off' , and then add the RHS Server to the 'Gluster Service Enabled Cluster' on RHEVM. So I believe that the fix for this BZ must be in the boot-strapping code, that is run on adding the RHS Server to the 'Gluster Service Enabled Cluster' on RHEVM. Additional Info: In RHEVM 3.2, the RHS Server is rebooted after the boot-strapping process, and so if glusterd is not ensured to start up at boot, the RHS server will be moved to 'non-responsive' state after the reboot, since glusterd will not be running. IN RHEVM3.3, the reboot after boot-strapping has been taken out, and hosts are immediately set to state up' after boot-strapping. Also during boot-strapping the glusterd and vdsm services are started up. So the effect of the scenario described by the reproducer will come up only on a reboot of the RHS Server, any-time in future.
Targeting for 2.1.z (Big Bend) U1.
currently bootstrap is done by host-deploy using otopi and they needs to have this fix.
upstream fix is under review at http://gerrit.ovirt.org/21743
This is an RFE and hence out of Corbett
Thank you for your report. This bug is filed against a component for which no further new development is being undertaken