Bug 840508

Summary: Need better practise on (not) editing /usr/share/java/conf/core-site.xml
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Niels de Vos <ndevos>
Component: doc-Administration_GuideAssignee: Divya <divya>
Status: CLOSED CURRENTRELEASE QA Contact: SATHEESARAN <sasundar>
Severity: high Docs Contact:
Priority: low    
Version: 2.0CC: asriram, flanagan, mhideo, rwheeler, sasundar, storage-doc, vshankar
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 854541 858427 (view as bug list) Environment:
Last Closed: 2015-04-10 07:17:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 854541, 858427    

Description Niels de Vos 2012-07-16 14:02:35 UTC
It is extremely rare that configuration files under /usr need to be edited. Page 152 (http://docs.redhat.com/docs/en-US/Red_Hat_Storage/2.0/html-single/Administration_Guide/index.html#id3047004) tells to make changes in /usr/share/java/conf/core-site.xml. I am wondering if there is not a better suitable file under /etc that can be used to overload the configuration. (Ah, page 153 tells to create a sym-link to the configuration directory. Maybe it's better practise to not link, but copy the configuration?)

Comment 1 Venky Shankar 2012-07-30 10:18:01 UTC
AJ mentioned that /usr/share/java is where jars get installed. You're right, that need not be the path for the configuration file. If /etc makes more sense for configuration files, I'm okay in moving core-site.xml somewhere there.

Regarding the sym-link thing, that's how we wanted it with upstream GlusterFS. If it's a good practice (RHS?) in copying the file over, then docs need to be updated.

Comment 2 Divya 2012-07-31 05:44:34 UTC
Niels,

Based on my discussion with VS and Venky, it was decided to move core-site.xml file to /var/lib/glusterd/. We will request AJ to move it and then update the doc.

Kindly confirm if copying the configuration file is the best practice instead of linking. Based on your confirmation, I will update the doc.

Regards,
Divya

Comment 3 Niels de Vos 2012-08-03 09:55:46 UTC
Hi Divya,

yes, copying a file from /usr/... to /var/lib/.. is fine. Contents under /usr should not be edited by administrators, /var/lib is definitely a better place for that.

It is possible that the original file under /usr/... is kept, and the administrator manually copies the file to /var/lib/... Automatically would be good too, but I don't know how practical that is.

Thanks,
Niels

Comment 4 Venky Shankar 2012-08-09 18:13:58 UTC
lets keep it in /var/lib/glusterd/glusterfs-hadoop/

administrator can manually copy the conf from this directory to whatever his $HADOOP_HOME is.

AJ, the spec file would need to change to drop the conf in the above mentioned directory.

Comment 5 Divya 2012-09-05 09:54:45 UTC
As suggested, I have changed instructions to copy files to respective location instead of creating symbolic links. 

The updated documentation is available at: http://documentation-devel.engineering.redhat.com/docs/en-US/Red_Hat_Storage/2.0/html/Administration_Guide/sect-Administration_Guide-GlusterFS_Client-CIFS.html#id1257909

Cloning this bug for Release Engineering to move the file to /var/lib/glusterd/glusterfs-hadoop/.

Comment 6 SATHEESARAN 2012-10-11 12:21:11 UTC
Moving this bug to VERIFIED state

Comment 7 SATHEESARAN 2012-10-11 12:25:34 UTC
Since this bug is blocked by 854541 -  again moving this bug to ON_QA state

Comment 8 SATHEESARAN 2012-11-19 09:16:17 UTC
First part of this bug is fixed - [ Copying instead of creating symbolic link] - is verified, but the latter part of moving the file /usr/share/java/conf/core-site.xml to /var/lib/glusterd/glusterfs-hadoop/core-site.xml will tracked seperately, as it is not yet implemented, in a new bug as discussed with Divya. So moving this bug to VERIFIED state