Grow storage to 2 TiB and upgrade Talos to v1.13.9

tepichord commented

2026-09-17 09:14:38 -07:00

Owner

The shared data disk goes 100 GiB -> 2 TiB, the worker system disk 40 GiB ->
1 TiB and the control-plane disk 40 GiB -> 128 GiB; Vault's 20 GiB disk is
unchanged. Memory moves to control-plane 3 GB / worker 15 GB (the host's 18 GiB
split), and both nodes move to Talos v1.13.9.

Two things the resize exposed, both fixed here:

A Talos user volume does not follow its disk on its own. A partition volume
is created at its provisioning size and stays there unless the
UserVolumeConfig sets provisioning.grow: true, so bumping the qcow2 alone
left /var/mnt/data at 100 GiB. Both worker volumes now declare grow.
OPERATIONS 12d's reconcile step was wrong: a terraform apply does not adopt
the host's new capacity (the provider's Read keeps the state value), so the
plan reports an in-place capacity update that the provider then refuses, on
every retry. The working procedure is state rm + import by pool path --
what data/restore.sh already does -- and an import reads back more than
Create ever wrote, so every volume now ignores the provider-reported
metadata (the ignore_changes lists were incomplete). They are
version-sensitive: control-plane still pins libvirt 0.9.8, which decides
allocation itself.

Refreshes the docs and plan-time assertions to the new sizes, corrects the
stale "20 GB worker" preview-quota comment, and ignores the state backups a
12d reconcile leaves behind.

The shared data disk goes 100 GiB -> 2 TiB, the worker system disk 40 GiB -> 1 TiB and the control-plane disk 40 GiB -> 128 GiB; Vault's 20 GiB disk is unchanged. Memory moves to control-plane 3 GB / worker 15 GB (the host's 18 GiB split), and both nodes move to Talos v1.13.9. Two things the resize exposed, both fixed here: * A Talos user volume does not follow its disk on its own. A `partition` volume is created at its provisioning size and stays there unless the UserVolumeConfig sets `provisioning.grow: true`, so bumping the qcow2 alone left /var/mnt/data at 100 GiB. Both worker volumes now declare grow. * OPERATIONS 12d's reconcile step was wrong: a `terraform apply` does not adopt the host's new capacity (the provider's Read keeps the state value), so the plan reports an in-place capacity update that the provider then refuses, on every retry. The working procedure is `state rm` + `import` by pool path -- what data/restore.sh already does -- and an import reads back more than Create ever wrote, so every volume now ignores the provider-reported metadata (the ignore_changes lists were incomplete). They are version-sensitive: control-plane still pins libvirt 0.9.8, which decides `allocation` itself. Refreshes the docs and plan-time assertions to the new sizes, corrects the stale "20 GB worker" preview-quota comment, and ignores the state backups a 12d reconcile leaves behind.

tepichord added 1 commit

2026-09-17 09:14:38 -07:00

Grow storage to 2 TiB and upgrade Talos to v1.13.9

ci/woodpecker/pr/gates Pipeline failed

Details

ci/woodpecker/pull_request_closed/cleanup Pipeline was successful

Details

d163ce473f

The shared data disk goes 100 GiB -> 2 TiB, the worker system disk 40 GiB ->
1 TiB and the control-plane disk 40 GiB -> 128 GiB; Vault's 20 GiB disk is
unchanged. Memory moves to control-plane 3 GB / worker 15 GB (the host's 18 GiB
split), and both nodes move to Talos v1.13.9.

Two things the resize exposed, both fixed here:

* A Talos user volume does not follow its disk on its own. A `partition` volume
  is created at its provisioning size and stays there unless the
  UserVolumeConfig sets `provisioning.grow: true`, so bumping the qcow2 alone
  left /var/mnt/data at 100 GiB. Both worker volumes now declare grow.

* OPERATIONS 12d's reconcile step was wrong: a `terraform apply` does not adopt
  the host's new capacity (the provider's Read keeps the state value), so the
  plan reports an in-place capacity update that the provider then refuses, on
  every retry. The working procedure is `state rm` + `import` by pool path --
  what data/restore.sh already does -- and an import reads back more than
  Create ever wrote, so every volume now ignores the provider-reported
  metadata (the ignore_changes lists were incomplete). They are
  version-sensitive: control-plane still pins libvirt 0.9.8, which decides
  `allocation` itself.

Refreshes the docs and plan-time assertions to the new sizes, corrects the
stale "20 GB worker" preview-quota comment, and ignores the state backups a
12d reconcile leaves behind.

tepichord merged commit 2ec5eb215f into main

2026-09-17 09:14:44 -07:00

tepichord deleted branch feat/grow-storage-upgrade-talos

2026-09-17 09:14:44 -07:00

tepichord referenced this pull request from a commit

2026-09-17 09:14:45 -07:00

Grow storage to 2 TiB and upgrade Talos to v1.13.9 (#65)

Rows
Columns

Grow storage to 2 TiB and upgrade Talos to v1.13.9 #65