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.
Since this bug is not a blocker, re-proposing this bug for RHGS 3.2
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.
Ref: https://github.com/gluster/gdeploy/commit/62d6f9b
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>
verified based on comment6
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