Bug 1683318

Summary:	Incorrect value set for poolmetadatasize
Product:	[oVirt] cockpit-ovirt	Reporter:	SATHEESARAN <sasundar>
Component:	Gdeploy	Assignee:	Gobinda Das <godas>
Status:	CLOSED CURRENTRELEASE	QA Contact:	SATHEESARAN <sasundar>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	0.12.2	CC:	bugs, dparth, godas, irosenzw, rhs-bugs, sabose, sankarshan
Target Milestone:	ovirt-4.3.3	Keywords:	Reopened
Target Release:	0.12.6	Flags:	sasundar: ovirt-4.3? godas: devel_ack+
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	cockpit-ovirt-0.12.6	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1683314	Environment:
Last Closed:	2019-04-16 13:58:30 UTC	Type:	---
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:	1683314

Description SATHEESARAN 2019-02-26 15:10:56 UTC

Description of problem:
-----------------------
Thinpool poolmetadatasize is set to 3MB and its very low. As per RHGS recommendation, thinpoolmetadatasize should have value 16GB. If storage is a concern, then 0.5% of thinpool size should be set as poolmetadatasize

Version-Release number of selected component (if applicable):
-------------------------------------------------------------
cockpit-ovirt-dashboard-0.12.3

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

Steps to Reproduce:
--------------------
1. Start RHHI-V deployment
2. Select thinpool for bricks ( disable VDO for bricks )

Actual results:
---------------
poolmetadatasize is set to 3MB

Expected results:
------------------
poolmetadatasize should be 16GB
(or)
0.5% of thinpoolsize, if storage is a concern

Additional info:
----------------

Ideally it should be:
poolmetadatasize = minimum( 16GB, 0.5% of thinpool size )

Comment 1 SATHEESARAN 2019-03-06 07:04:11 UTC

With cockpit-ovirt-dashboard-0.12.3, the poolmetadatasize is calculated correctly with various values for brick size.
Not sure, on which occasion, we hit this problem.

Right away, closing this bug.

Comment 2 SATHEESARAN 2019-03-20 10:49:35 UTC

(In reply to SATHEESARAN from comment #1)
> With cockpit-ovirt-dashboard-0.12.3, the poolmetadatasize is calculated
> correctly with various values for brick size.
> Not sure, on which occasion, we hit this problem.
> 
> Right away, closing this bug.


Re-opening this bug as the value for poolmetadatasize lacks the UNIT and by default
lvm considers that as MB

<snip_from_inventory_file>
 - vgname: gluster_vg_sdb
          thinpoolname: gluster_thinpool_gluster_vg_sdb
          poolmetadatasize: 16
        - vgname: gluster_vg_sdb
          thinpoolname: gluster_thinpool_gluster_vg_sdb
          poolmetadatasize: 16
</snip_from_inventory_file>


<snip_from_var_log_messages>
Mar 20 14:03:09 dhcp37-83 python: ansible-lvol Invoked with pvs=None force=False vg=gluster_vg_sdb lv=None resizefs=False state=present thinpool=gluster_thinpool_gluster_vg_sdb snapshot
=None active=True shrink=False opts= --chunksize 2560K#012 --poolmetadatasize 16 --zero n size=100%FREE
</snip_from_var_log_messages>

The exact unit should be the same as thinpool size. 0.005 X ( thinpool_size ) unit

Comment 3 SATHEESARAN 2019-03-29 18:42:35 UTC

Verified with cockpit-ovirt-dashboard-0.12.6

Poolmetadatasize of thinpool is set as per requirement - 0.5% of thinpool size

Snip from the generated ansible vars file
-------------------------------------------

      gluster_infra_thinpools:
        - vgname: gluster_vg_sdc
          thinpoolname: gluster_thinpool_gluster_vg_sdc
          poolmetadatasize: 3G
      gluster_infra_lv_logicalvols:
        - vgname: gluster_vg_sdc
          thinpool: gluster_thinpool_gluster_vg_sdc
          lvname: gluster_lv_vmstore
          lvsize: 500G

Comment 4 Sandro Bonazzola 2019-04-16 13:58:30 UTC

This bugzilla is included in oVirt 4.3.3 release, published on April 16th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.3 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.