Feature Overview (aka. Goal Summary)  

Currently, LVMS does not touch a disk if it suspects that their might still be data on it (e.g. partitions, filesystems, volume groups etc.). This is to protect customers from data loss. Customers would need to manually access the host and wipe the disks themself. This is inconvienent, esp. in automated test setups where a server might be in an unknown state and manual intervention is not wanted. 

The goal of this feature is to provide an attribute in the LVMS CRD that admins can set to force wipe delete the selected disks.

Goals (aka. expected user outcomes)

be able to force wipe disks, but only when disks are defined explicitly via their paths.

Requirements (aka. Acceptance Criteria):

Change the LVMCluster CRD with an new, optional attribute 

spec.storage.deviceClasses[n].deviceSelector.forceWipeDevicesAndDestroyAllData

of type Boolean with default = false.

If that attribute is set to true, each disk listed under the deviceSelector.paths|optionalPaths  attributes are wiped out using "wipefs --all --force <path>"

The action is to be logged on a log level that is usually enabled in a standard deployment (e.g. warning or info).

Out of Scope

LVMS has an 'auto' mode where it grabs all suitable disks, i.e. when no deviceSelector is given, all unused disks are used. In this 'auto' mode, no wiping of disks is happening. It would be far too dangerous to accidentally wipe an important disk.

Documentation Considerations

Docs need to be updated, in the sections:

• Creating a Logical Volume Manager cluster
• LVM Storage reference YAML file

Interoperability Considerations

Local Storage Operator is going to implement a similiar attribute. We should align / standardize on the exact name of that attribute. It should really point out explicititly that this might induce loss of data.

Size

Eng: M - API change, plumbing the functionality through the API to the CSI driver.

Docs: M - Gigantic warning in the docs. Existing examples need modification to include the API change.

QE: L - Requires many testing permutations. Will need to test how this works when software RAID is configured. Full regression testing on SNO and multi-node footprints.