Add pvresize before lvextend

[seunghun1ee]

Running pvresize before lvextend ensures that there is enough space for extension.

There are some cases where lvextend fails because initial usable space of a physical volume is not enough.
This leads the automated setup failure at package or python module installation stage.
As this happens earlier than kayobe setup, kayobe playbook run etc/kayobe/ansible/growroot.yml can't be used.

stackhpc-kayobe-config/etc/kayobe/ansible/growroot.yml

Lines 87 to 93 in e1a64bd

	- name: Grow LVM PV
	command: "pvresize {{ disk }}"
	vars:
	pv: "{{ pvs.stdout | from_json }}"
	disk: "{{ pv.report[0].pv[0].pv_name }}"
	become: true
	when: lvm_check.rc == 0 or growroot_ignore_lvm_check

Therefore I propose adding bash equivalent of the Ansible task above before lvextend.

The command gets the name of the physical volume by filtering the output of sudo pvs --noheadings.
head -n 1 is used to take first line of output only then awk '{print $1}' is used to take first element of it, which is essentially the way the growroot.yml does to get PV name.

[Alex-Welsh]

Growroot is no longer required if pvresize is being run early on, so you can delete this line

[Alex-Welsh]

LGTM but two notes:

1. Your change could be one line:
   sudo pvresize $(sudo pvs --noheadings | head -n 1 | awk '{print $1}')

2. It's a bit of a shame we don't use growroot anymore, but I think it's more important to keep this script clean and consistent than to try and have some complex conditional that does both a pvresize and growroot.

[seunghun1ee]

1. Your change could be one line:
   sudo pvresize $(sudo pvs --noheadings | head -n 1 | awk '{print $1}')

Yeah I agree. Looks like setting a variable is not needed here.

[seunghun1ee]

@markgoddard What do you think of also making PR with this change for stackhpc/zed and stackhpc/2023.1?

[markgoddard]

@markgoddard What do you think of also making PR with this change for stackhpc/zed and stackhpc/2023.1?

We merge changes forwards in this repo, so they will get fixed automatically. I can propose some merges.

[seunghun1ee]

@markgoddard What do you think of also making PR with this change for stackhpc/zed and stackhpc/2023.1?

We merge changes forwards in this repo, so they will get fixed automatically. I can propose some merges.

Thanks Mark