Files

JARVIS f57e0bef02 feat(day0): promote expand_root_lv to a canonical day0 step

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.

2026-05-30 23:08:35 -05:00

defaults

feat(expand_root_lv): new role to grow root LV to fill VG + resize fs

2026-05-30 23:03:10 -05:00

README.md

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:

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.