Drop the home PVC migration import, keep the removed block #7

Merged

GuillaumeHemmen merged 1 commit from chore/pvc-v1-migration-cleanup into master

2026-09-30 09:13:53 +00:00

claude-bot commented

2026-09-30 09:13:18 +00:00

Member

Step 2 of 2 for the kubernetes_persistent_volume_claim → _v1 migration (#6).

Migration result

All workspaces were updated to the #6 template and restarted. Home PVCs verified on the cluster afterwards:

Workspace	PVC UID	Created	Result
ghe-perso	`46f76366…`	2026-05-30	same volume, resourceVersion unchanged since before the migration
beewise	`f0194552…`	2026-05-30	same volume
red-reindeer-86 (test)	`83d83509…`	2026-09-30	same volume; `~/toto.txt` survived two builds on the migration version

Change

Removed the kubernetes_persistent_volume_claim_v1.existing_home data source and the import block.
Kept the removed { destroy = false } block, permanently, with a comment explaining why. For a workspace that somehow missed the migration, it turns what would be a destroy of its home PVC (reclaimPolicy Delete) into a harmless already exists error on create. The fix in that case is to re-run #6's import.

Tested (plan only, Terraform 1.14.5 / kubernetes v3.2.1)

Scenario	PVC plan	Destroy
Migrated workspace (`_v1` in state, ghe-perso's real PVC)	`_v1`: update	0
Straggler (old address still in state)	old: `forget`, `_v1`: `create` (would fail "already exists")	0

terraform validate: valid, no warnings.

🤖 Generated with Claude Code

Step 2 of 2 for the `kubernetes_persistent_volume_claim` → `_v1` migration (#6). ## Migration result All workspaces were updated to the #6 template and restarted. Home PVCs verified on the cluster afterwards: | Workspace | PVC UID | Created | Result | |---|---|---|---| | ghe-perso | `46f76366…` | 2026-05-30 | same volume, resourceVersion unchanged since before the migration | | beewise | `f0194552…` | 2026-05-30 | same volume | | red-reindeer-86 (test) | `83d83509…` | 2026-09-30 | same volume; `~/toto.txt` survived two builds on the migration version | ## Change - **Removed** the `kubernetes_persistent_volume_claim_v1.existing_home` data source and the `import` block. - **Kept** the `removed { destroy = false }` block, permanently, with a comment explaining why. For a workspace that somehow missed the migration, it turns what would be a **destroy of its home PVC** (reclaimPolicy Delete) into a harmless `already exists` error on create. The fix in that case is to re-run #6's import. ## Tested (plan only, Terraform 1.14.5 / kubernetes v3.2.1) | Scenario | PVC plan | Destroy | |---|---|---| | Migrated workspace (`_v1` in state, ghe-perso's real PVC) | `_v1`: update | 0 | | Straggler (old address still in state) | old: `forget`, `_v1`: `create` (would fail "already exists") | **0** | `terraform validate`: valid, no warnings. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit

2026-09-30 09:13:18 +00:00

Drop the home PVC migration import, keep the removed block 3ed6f672db

Step 2 of the kubernetes_persistent_volume_claim -> _v1 migration (#6).
All workspaces have built on the migration version and kept their PVCs,
so the existence check and the import block are no longer needed.

The removed block stays on purpose: for a workspace that missed the
migration it turns what would be a destroy of its home PVC into a
harmless 'already exists' error on create.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>