The half-disk LV pattern affects ~90% of mk-labs VMs. Treating the
fix-up as application-specific (as it was in day1_deploy_honcho.yml)
means future deploys would each carry the same boilerplate, and any
day1 author could forget it.
This commit:
* Adds playbooks/day0_expand_root_lv.yml — standalone day0 step,
targets {{ target | default("all") }}, honors a per-host
expand_root_lv_skip opt-out for multi-LV layouts.
* Adds playbooks/day0_provision.yml — umbrella playbook chaining
day0_linux_baseline + day0_expand_root_lv, so the operator runs
ONE command per new VM.
* Removes expand_root_lv from day1_deploy_honcho.yml — day0 is
assumed complete before day1 begins (cleaner separation of
concerns, matches the convention day1_deploy_semaphore already
follows).
* Updates the role README to document the lifecycle position and
the opt-out flag for hosts with multi-LV plans.
71 lines
2.7 KiB
Markdown
71 lines
2.7 KiB
Markdown
# expand-root-lv role
|
|
|
|
Idempotent role that extends the root LVM logical volume to fill its
|
|
volume group and grows the underlying filesystem (ext4 or xfs).
|
|
|
|
## Where this runs in the lifecycle
|
|
|
|
Part of the **day0** host-provisioning lifecycle. The canonical entry
|
|
points are:
|
|
|
|
```
|
|
playbooks/day0_expand_root_lv.yml # standalone
|
|
playbooks/day0_provision.yml # umbrella (baseline + expand_root_lv)
|
|
```
|
|
|
|
Day1 application-deploy playbooks should NOT include this role —
|
|
day0 is assumed complete before day1 begins.
|
|
|
|
## Why this role exists
|
|
|
|
The Ubuntu Server autoinstall template (used by the mk-labs `wed`-baked
|
|
VM templates) provisions the root LV at roughly half the available disk
|
|
size — a longstanding installer default that surprises every operator
|
|
who hasn't been bitten by it before. ~90% of mk-labs VMs need this
|
|
fix-up before they're fully useful.
|
|
|
|
## Idempotency
|
|
|
|
- If `vg_free_count == 0`, the `lvextend` step is skipped and the
|
|
filesystem-grow step is also skipped (nothing to resize against).
|
|
- If the target volume group doesn't exist on the host (e.g. a non-LVM
|
|
layout), the role exits cleanly via `meta: end_play`.
|
|
- Safe to leave in a recurring playbook so future disk expansions
|
|
(Proxmox-side disk grow → reboot → run role) are picked up
|
|
automatically.
|
|
|
|
## Opt-out for multi-LV hosts
|
|
|
|
If a host will have a **second logical volume in the same VG** (e.g. a
|
|
dedicated `/var/lib/postgresql` LV for a database server), this role's
|
|
"grow root to fill VG" behavior is wrong — it will consume the free PE
|
|
that was being reserved for the second LV.
|
|
|
|
Set in `host_vars/<host>.yml`:
|
|
|
|
```yaml
|
|
expand_root_lv_skip: true
|
|
```
|
|
|
|
The day0 playbook checks this flag and skips the role cleanly.
|
|
|
|
## Defaults
|
|
|
|
| Variable | Default | Purpose |
|
|
|-------------------------------|---------------|-----------------------------------------------------|
|
|
| `expand_root_lv_vg_name` | `ubuntu-vg` | LVM volume group name (Ubuntu installer default). |
|
|
| `expand_root_lv_lv_name` | `ubuntu-lv` | LVM logical volume name (Ubuntu installer default). |
|
|
| `expand_root_lv_mountpoint` | `/` | Mountpoint of the filesystem to grow. |
|
|
|
|
Override the VG/LV names in `host_vars/<host>.yml` for hosts that use a
|
|
different LVM layout.
|
|
|
|
## Limitations
|
|
|
|
- Does not extend the underlying partition. If the operator grows the
|
|
Proxmox disk and the partition itself needs to grow before lvextend
|
|
can claim the new space, run `growpart /dev/sda 3` (or equivalent)
|
|
first. A future enhancement could automate this via `cloud-utils`'
|
|
`growpart` package, but it's out of scope for the initial template
|
|
fix-up case where the partition already covers the whole disk.
|