dwlehman / linux-storage-role Goto Github PK

For LVM, we need to be able to manage PVs in several different ways:

1. define set of disks on which to create PVs
2. define set of existing block devices to set as PVs for the VG
3. define set of existing block devices to set as PVs for a specific LV

Users will eventually need to be able to define a set of PVs for a specific LV without implicitly
also modifying the VG's PV set.

My current thinking is that #2 and #3 need to be controlled through two distinct variables.
PVs for the VG could either be lvm_pvs or lvm_vg_pvs, while PVs for a specific LV could
be lvm_lv_pvs.

Add functionality to allow adding scratch storage to test runs started via https://github.com/linux-system-roles/test-harness.

Make use of #2 to generate default vg and lv names.

• The package installations are currently divided into multiple files, which will be executed multiple times depending on the structure of the storage layout in tests/test.yml
• Moving to the start of the task flow minimizes the overall execution time in the playbook
• Have to decide between doing a pre-check of the user's system and installing all missing packages from a list of defined packages, or checking what fs types will be used in the playbook run so the user won't have unneeded packages installed.

When running a role with the size variable in the form of either 'x%PVS' or 'x%VG', the lvol module produces undesired effects.

1. If you initialize the size variable as follows: size: '50%VG', and want to use the VG foo, then it's possible that the size of the logical volume is not the expected size. In the case where you have an outstanding logical volume in the VG foo, whose size exceeds the specified 50%VG, then the lvol module will create a logical volume with the remaining space in foo, instead of the specified percentage.

2. When re-running the same playbook described above, the lvol module will attempt to resize the existing logical volume created in the previous run. The playbook will fail when there's not enough space to resize, and the following error will be produced:

TASK [linux-storage-role : Make sure LV exists] *****************************************************************************************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Logical Volume test2 could not be extended. Not enough free space left (3074.0m required / 0m available)"}

Make use of #4 to translate user-specified sizes to formats usable by the various tools.

This will involve changes to tasks/main.yml, tasks/lv-default.yml. The approach I would take initially is to use the size module to set a register in tasks/main.yml and then use the appropriate field when invoking the lvg module in tasks/lv-default.yml.

NOTES

We do plan to support percentage-based sizes. There is some question of whether we should only support plain/generic percentages (eg: "100%", "75%") or whether we should also support the lvm-specific percentage syntax (eg: "100%VG", "50%FREE"). It seems clear that the lvm-specific version will only make sense under some circumstances, so we will need to handle the cases where it doesn't make sense by failing early with an appropriate error message.

Make use of #5 to supply a default disk set.

Somewhere near the top of tasks/main.yml we should check if the user specified a disk set (disks). If not, we should invoke the find_unused_disk module to identify one unused disk and use that as the disk set for the role.

Before running any lvm commands, for example, we should ensure that the package is installed.

1. Create/Remove partition tables (msdos, gpt)
2. Create/Remove partitions (disk(s), size, flags)

Change modules to GPLv3+, role to MIT.

1. Create/Remove luks layer on leaf device (device, cipher, key size, key file)
2. Automatic crypttab management
3. Vaulted passphrase handling (stretch goal)
4. Create/Remove luks layer on LVM PV layer (stretch goal)