Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem ====================== Script enable_vol.sh doesn't ignore commented lines in /etc/fstab when it tries to verify it. This may lead to unnecessary failure during brownfield usecase. Version-Release number of selected component (if applicable) ============================================================ rhs-hadoop-install-2_29-1.el6rhs.noarch Steps to Reproduce ================== Follow RHS Installation Guide with brownfield cluster: 1. When checking gluster volume mount options, comment out the original line, while adding new with required mount options, eg: ~~~ #localhost:/BrownFieldVolume /mnt/brownfield glusterfs defaults,_netdev 0 0 localhost:/BrownFieldVolume /mnt/brownfield glusterfs entry-timeout=0,attribute-timeout=0,use-readdirp=no,_netdev 0 0 ~~~ 2. Run enable_vol.sh Actual results ============== The script fails because it doesn't ignore comments in /etc/fstab file: ~~~ ERROR: issues with 1 or more nodes spanned by BrownFieldVolume A suggestion is to re-run the setup_cluster.sh script to ensure that all nodes in the cluster are set up correctly for Hadoop workloads. See the /var/log/rhs-hadoop-install.log log file for additional info. ~~~ The error in the log is: ~~~ --- 10.16.66.77: live BrownFieldVolume mount options check... --- 10.16.66.77: /etc/fstab BrownFieldVolume mount options check... ERROR on 10.16.66.77: BrownFieldVolume appears more than once in /etc/fstab --- 10.16.64.42: live BrownFieldVolume mount options check... --- 10.16.64.42: /etc/fstab BrownFieldVolume mount options check... ERROR on 10.16.64.42: BrownFieldVolume appears more than once in /etc/fstab --- 10.16.67.178: live BrownFieldVolume mount options check... --- 10.16.67.178: /etc/fstab BrownFieldVolume mount options check... ERROR on 10.16.67.178: BrownFieldVolume appears more than once in /etc/fstab --- 10.16.67.194: live BrownFieldVolume mount options check... --- 10.16.67.194: /etc/fstab BrownFieldVolume mount options check... ERROR on 10.16.67.194: BrownFieldVolume appears more than once in /etc/fstab ~~~ Expected results ================ The script ignores comments in /etc/fstab and so it doesn't fail. Additional info =============== This is low impact bug, because admin will easily figure how to fix this issue. On the other hand, this may happen to anyone enabling hadoop on existing gluster volume (brownfield use case). Since admin needs to recheck/change mount options on RHS Server nodes, he may like to save the previous configuration in the comment. Additional question: does it mean that having multiple mount points on the RHS Server nodes would break something?
"does it mean that having multiple mount points on the RHS Server nodes would break something?" The glusterfs-fuse mount fstab entry should still only appear once, even though there are multiple brick mounts for a volume, right?
(In reply to Jeff Vance from comment #2) > The glusterfs-fuse mount fstab entry should still only appear once, even > though there are multiple brick mounts for a volume, right? Yep. But my question was a bit different: is there any reason why mounting the hadoop enabled gluster volume more than once is a bad idea? Note that this question is not directly related to the issue being reported/fixed here.
It's been mentioned by our team that the user may want different vol mounts to support different mount options. So, we could see: /mnt/glusterfs1/HadoolVol and /mnt/glusterfs2/HadoopVol bin.check_volmnt.sh will be changed to search for the volume mount rather than just the volume name. It is still expected that there will be only 1 mount per active volume, even if the volname appears in /etc/fstab more than once.
Fixed in 2.39
Tested with rhs-hadoop-install-2_44-1.el6rhs.noarch and it works. -->VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-0761.html