# 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).

## 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 everyone who
hasn't been bitten by it before. Every freshly-provisioned VM in mk-labs
needs this fix-up before it's 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 day1 deploy playbook so future disk expansions
  (Proxmox-side disk grow → reboot → run role) are picked up
  automatically.

## Usage

Standalone:

```yaml
- hosts: lincoln
  become: true
  roles:
    - expand_root_lv
```

Or chained ahead of an application role in a day1 playbook:

```yaml
- hosts: honcho_server
  become: true
  roles:
    - expand_root_lv
    - honcho
```

## 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 these in `host_vars/<host>.yml` for hosts that use a different
LVM layout. Hosts without LVM are silently no-op'd.

## 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.