Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 2178905

Summary: [RFE] Add THT parameter to pass thin_pool_autoextend_threshold value during overcloud deployment
Product: Red Hat OpenStack Reporter: schari
Component: openstack-tripleoAssignee: James Slagle <jslagle>
Status: CLOSED DUPLICATE QA Contact: Joe H. Rahme <jhakimra>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 17.1 (Wallaby)CC: bshephar, mburns, sbaker, schari
Target Milestone: ---   
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: Environment:
Last Closed: 2023-03-20 19:45:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description schari 2023-03-16 05:38:59 UTC 
Description of problem:
In OSP 17.1(and 17.0), because of growvols, the root disk of all baremetal nodes booted with the UEFI image is formatted with LVM.

The value for thin_pool_autoextend_threshold is set to 100 by default on all baremetal nodes. This means that the thin pools will not be extended even if they become full.

This sometimes causes issues after overcloud deployment when a large container image is pulled on a baremetal node. The thin pool usage reaches 100%, and the node crashes and does not recover after reboot because of [1]. The only reliable way to fix the issue in this scenario seems to be to unprovision the node and provision it again.

Setting thin_pool_autoextend_threshold to a value like 70 or 80 in /etc/lvm/lvm.conf on the baremetal nodes before running overcloud deployment seems to prevent the issue. It would be useful for thin_pool_autoextend_threshold to be a THT parameter so we can avoid manually setting the value on each baremetal node.

[1] https://access.redhat.com/solutions/5529921

Version-Release number of selected component (if applicable):
17.1_20221129.1
Comment 1 Steve Baker 2023-03-20 19:45:32 UTC 
17.1_20221129.1 is missing the fix to grow the thin pool metadata volume to a useful size[1], this made it into a package on December 23. Without this change any write activity might fill the metadata volume, but 1GiB should be enough for a full lifecycle of disk changes.

17.1_20221129.1 is very old and we would always strongly encourage using the latest compose when we're before RC.

[1]https://review.opendev.org/c/openstack/diskimage-builder/+/868049

*** This bug has been marked as a duplicate of bug 2149586 ***