Bug 1335080

Summary: cachemode should be available under 'lvs' section while setting-up the cache
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: SATHEESARAN <sasundar>
Component: gdeployAssignee: Sachidananda Urs <surs>
Status: CLOSED ERRATA QA Contact: SATHEESARAN <sasundar>
Severity: high Docs Contact:
Priority: unspecified    
Version: rhgs-3.1CC: amukherj, pcuzner, rcyriac, rhinduja, sabose, smohan, surs
Target Milestone: ---Keywords: ZStream
Target Release: RHGS 3.1.3 Async   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: gdeploy-2.0.1-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-02-07 11:33:03 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: 1277939, 1351522    

Description SATHEESARAN 2016-05-11 10:14:53 UTC 
Description of problem:
-----------------------
lvmcache supports the cache-modes viz- writeback, writethrough .
When a user wants to configure the cachemode using gdeploy, he need to create a section 'lvconvert' to achieve this, which is a burden

But there should be a option 'cachemode' under 'lvs' section too, and that value , if provided, should be carried over to 'lvconvert' section, so that the user is not having a burden to create lvconvert section just for mentioning the cachemode

Version-Release number of selected component (if applicable):
--------------------------------------------------------------
gdeploy-2.0-11

How reproducible:
-----------------
Always

Steps to Reproduce:
-------------------
NA

Actual results:
----------------
No way to mention the cachemode while creating the 'lvs' under the action 'setup-cache'

Expected results:
-----------------
'lvs' should have an option 'cachemode' which is carried over to 'lvconvert' section, if value is provided.
Comment 1 SATHEESARAN 2016-05-20 08:08:39 UTC 
Since this bug is not a blocker, re-proposing this bug for RHGS 3.2
Comment 3 Paul Cuzner 2016-07-13 21:57:38 UTC 
Also note that the actions taken should be different for the different cachemode options. 

For example, 

writethrough mode: the input device list is simple one SSD. Data loss in this scenario from a failed SSD is nil.

writeback mode: the input device list needs to be at least 2. The ssd layer will know hold on to writes, so the loss of an ssd presents the opportunity for data loss. In this mode the SSD's should be configured as a RAID-1 set.

I suggest this is the default behaviour. You may need to add a 'force' option if the admin wants to bypass the recommended RAID-1 config.
Comment 5 Sachidananda Urs 2016-09-09 08:03:39 UTC 
Ref: https://github.com/gluster/gdeploy/commit/62d6f9b
Comment 6 SATHEESARAN 2016-11-09 11:05:42 UTC 
Tested with gdeploy-2.0.1-3.el7rhgs

'cachemode' option is valid under the section 'lv' and it created 'writeback' cache if mentioned, and created a write-through cache by default.

status of the cache as seen post using 'cachemode=writeback' in config file

<snip>
RHGS_vg1-lvthinpool_tdata: 0 10485760 cache 8 250/2048 128 75/81920 562 77 7 3 0 75 0 1 writeback 2 migration_threshold 2048 smq 0 rw - 
</snip>
Comment 7 SATHEESARAN 2016-11-09 11:06:04 UTC 
verified based on comment6
Comment 9 errata-xmlrpc 2017-02-07 11:33:03 UTC 
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/RHSA-2017-0260.html