Bug 1608271

Summary: Support lvm cache for thickpool configuration
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: bipin <bshetty>
Component: gdeployAssignee: Sachidananda Urs <surs>
Status: CLOSED WONTFIX QA Contact: SATHEESARAN <sasundar>
Severity: high Docs Contact:
Priority: unspecified    
Version: rhhiv-1.5CC: bshetty, bugs, fhirtz, rhs-bugs, sabose, sankarshan, sasundar, smohan, storage-qa-internal, vdas
Target Milestone: ---Keywords: ZStream
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1608268 Environment:
Last Closed: 2018-10-22 06:01:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Gluster RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1608268    

Description bipin 2018-07-25 08:47:06 UTC
+++ This bug was initially created as a clone of Bug #1608268 +++

Description of problem:
======================
While deploying gluster using gdeploy,currently the lvm cache is supported only on a thinpool volume. Need to support for thickpool lv configuration as well.
In the latest deployment, while configuring the lvm cache on a thickpool lv it throws the below error.


TASK [Setup SSD for caching | Change the attributes of the logical volume] *****
fatal: [10.70.45.29]: FAILED! => {"msg": "The conditional check 'res.rc != 0 and 'zero new blocks' not in res.msg' failed. The error was: error while evaluating conditional (res.rc != 0 and 'zero new blocks' not in res.msg): 'dict object' has no attribute 'rc'"}
	to retry, use: --limit @/tmp/tmp3b4PFo/cache_setup.retry



Version-Release number of selected component (if applicable):
============================================================
gdeploy-2.0.2-27.el7rhgs.noarch
ansible-2.6.1-1.el7ae.noarch

How reproducible:
================
100%

Steps to Reproduce:
==================
1.Navigate to the cockpit UI
2.Start the gluster deployment 
3.Move towards the brick and check the enable compression and deduplication checkbox
4.The thinpool gets unchecked for that device and enable the lvm cache
5.Proceed towards the deployment and it fails

Actual results:
==============
Fails with error

Expected results:
================
Shouldn't fail

Additional info:
===============
Additionally tried attaching lvmcache to thick lv within the gdeploy script( Changing the poolname to the lv name) but it failed.
Here is the conf file:
[hosts]
10.70.37.146

[lv]
action=setup-cache
ssd=vdd
vgname=vg1
poolname=lv1
cache_lv=lvcache
cache_lvsize=9GB
cachemode=writethrough
ignore_lv_errors=no

Here is the output:
[root@rhsqa-grafton7 ~]# gdeploy -c gdeployConfig.conf 

PLAY [gluster_servers] ***************************************************************************************************************************

TASK [Setup SSD for caching | Create the physical volume] ****************************************************************************************
changed: [10.70.37.146] => (item=/dev/vdd)

TASK [Setup SSD for caching | Extend the Volume Group] *******************************************************************************************
changed: [10.70.37.146] => (item=/dev/vdd)

TASK [Setup SSD for caching | Change the attributes of the logical volume] ***********************************************************************
fatal: [10.70.37.146]: FAILED! => {"changed": false, "failed_when_result": true, "msg": "  Command on LV vg1/lv1 uses options that require LV types thinpool .\n  Command not permitted on LV vg1/lv1.\n", "rc": 5}
	to retry, use: --limit @/tmp/tmpuYsXsi/cache_setup.retry

PLAY RECAP ***************************************************************************************************************************************
10.70.37.146               : ok=2    changed=2    unreachable=0    failed=1

Comment 2 Sachidananda Urs 2018-07-26 09:42:20 UTC
Can you please paste the complete config file?

Comment 4 Vivek Das 2018-08-12 16:26:07 UTC
Moving this bug out of 3.4.0 as this doesn't meet blocker criteria. This can be re-proposed for 3.4.0 if required.

Comment 6 SATHEESARAN 2018-10-01 11:02:33 UTC
The case differs only in the place where the cachepool LV is attached to the OriginLV. 

With thinpool - Cachepool LV is attached to the VG/thinpool
non-thinpool  - Cachepool LV is attached to the VG/origin_lv

To enable support for this request, the parameter 'poolname' should be made optional and one more parameter 'origin_lv' should be made available. These 2 parameters 'poolname' & 'origin_lv' should be mutually exclusive, which means only one of them should be available.

If this param 'poolname' is available, attach cachepool to VG/thinpool, else look for param 'origin_lv' and attach cache to 'VG/origin_lv'


Let me also furnish the steps used to create the lvmcache which could also enabled the understandig.

Variables
------------
SSD - /dev/sdc ( say 225G )
HDD - /dev/sdb 
VG name - gluster_vg_sdb

With thinpool
-------------
thinpool name - gluster_thinpool_sdb

1. Add the SSD to the VG
# vgextend gluster_vg_sdb /dev/sdc

2. Create 'cachelv'
# lvcreate -n cachelv -L 220G vg1 /dev/sdc

3. Create 'cachepool'
# lvconvert --type cache-pool vg1/cachelv

4. Attach the 'cachepool' to the thinpool
# lvconvert --type cache vg1/cachelv vg1/gluster_thinpool_sdb

Without thinpool (ie.) with thick LVs
-------------------------------------
Let's say one of the thick LV name is 'lv1'

1. Add the SSD to the VG
# vgextend gluster_vg_sdb /dev/sdc

2. Create 'cachelv'
# lvcreate -n cachelv -L 220G vg1 /dev/sdc

3. Create 'cachepool'
# lvconvert --type cache-pool vg1/cachelv

4. Attach the 'cachepool' to the thick LV ( as per requirement )
# lvconvert --type cache vg1/cachelv vg1/lv1

Comment 7 Sachidananda Urs 2018-10-22 06:01:37 UTC
@sas @bipin we are not planning to do this in gdeploy but will be taking care of this in gluster-ansible. I'll be closing this bug, feel free to reopen if you want this feature in gdeploy.