OCP/Telco Definition of Done
Epic Template descriptions and documentation.

<--- Cut-n-Paste the entire contents of this description into your new Epic --->

Epic Goal

LVMS with thin provisioning creates a thin pool that requires metadata for the block mapping. The size of the metadata is currently not set explicitly in LVMS, so a default value is calculated by lvm2, which could lead to problems if this default is too small.

The goal of this epic is to allow configuring this setting so that users can pick a value that fits best to their use case.  

Why is this important?

• If the metadata runs full, the system will fail with probable loss of data, and it's hard to recover from this situation.

Scenarios

1. The user would like to set a default value for thin pool metadata size that fits best to their use case.
2. The user would like to increase the metadata size after initial installation. Shrinking metadata size is not supported, as it's not supported by lvm2.
3. The user would like to use the host lvm2 settings without setting a value in LVMS.
4.  

Acceptance Criteria

• A user can configure metadata size either through a field in LVMCluster or using host settings.
• The field can be modified to increase the metadata size after the initial deployment. 
• The solution does not break backward compatibility.

Dependencies (internal and external)

Previous Work (Optional):

1. A spike to refine the epic: https://issues.redhat.com/browse/OCPEDGE-1209 
2. Although https://issues.redhat.com/browse/OCPBUGS-34227 is not directly related, it also provided a way to configure the chunk size using a policy field. We would need a similar field to choose either host settings or static settings through LVMS.

Open questions:

1. Is auto-extension of metadata size in the scope of this epic? A: No. However, by introducing a policy field in the API, we make the API extensible by adding new policies like "auto-extension" in the future. 

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>