+++ 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
Can you please paste the complete config file?
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.
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
@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.