Bug 1335080 - cachemode should be available under 'lvs' section while setting-up the cache
Summary: cachemode should be available under 'lvs' section while setting-up the cache
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: gdeploy
Version: rhgs-3.1
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: RHGS 3.1.3 Async
Assignee: Sachidananda Urs
QA Contact: SATHEESARAN
URL:
Whiteboard:
Depends On:
Blocks: Gluster-HC-2 1351522
TreeView+ depends on / blocked
 
Reported: 2016-05-11 10:14 UTC by SATHEESARAN
Modified: 2017-03-07 17:41 UTC (History)
7 users (show)

Fixed In Version: gdeploy-2.0.1-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-07 11:33:03 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:0260 normal SHIPPED_LIVE Important: ansible and gdeploy security and bug fix update 2017-02-07 16:32:47 UTC

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


Note You need to log in before you can comment on or make changes to this bug.