Pin the kubernetes provider and move the deployment to kubernetes_deployment_v1 #5

Merged

GuillaumeHemmen merged 1 commit from chore/deployment-v1-pin-kubernetes into master

2026-09-30 08:18:26 +00:00

claude-bot commented

2026-09-30 08:13:34 +00:00

Member

Why

The template push log (2026-09-30 08:10 UTC) shows:

hashicorp/kubernetes: Finding latest version...
Installed provider version: hashicorp/kubernetes v3.2.1
...
Warning: Deprecated Resource  (main.tf:291 kubernetes_persistent_volume_claim.home)
Warning: Deprecated Resource  (main.tf:321 kubernetes_deployment.main)

The provider has no version constraint, so every push floats to the newest release. v3.0 deprecated all un-suffixed resources; a future major removing them would break every workspace build on the next push, with no warning beyond these lines.

Change

Pin hashicorp/kubernetes to ~> 3.2, the version already in use, so behaviour doesn't change today.
kubernetes_deployment → kubernetes_deployment_v1. In the provider both names map to the same implementation (resourceKubernetesDeploymentV1, kubernetes/provider.go:292-293), so the schema is identical. The deployment is count = start_count: it is destroyed on every stop and created on every start, so the type change costs nothing beyond a normal restart. No data involved.

Deliberately not changed: the home PVC

kubernetes_persistent_volume_claim.home keeps its deprecation warning. It is the one persistent resource, and renaming its type would make Terraform destroy and recreate every workspace's home volume. A moved block can't help: cross-type moves need provider support, and v3.2.1's MoveResourceState is a no-op stub (manifest/provider/server.go:115).

Migrating it safely needs removed { lifecycle { destroy = false } } + an import block, with the import made conditional so fresh workspaces (no PVC yet) don't fail. That deserves its own PR and a test against a throwaway workspace. The pin above keeps the deprecated type available until then.

Validation

terraform init + terraform validate with Terraform 1.14.5 (same as the Coder provisioner): valid, providers resolve to coder v2.18.0 / kubernetes v3.2.1 / http v3.6.2, only the intentional PVC warning left. Not plan/applied against a real workspace.

🤖 Generated with Claude Code

## Why The template push log (2026-09-30 08:10 UTC) shows: ``` hashicorp/kubernetes: Finding latest version... Installed provider version: hashicorp/kubernetes v3.2.1 ... Warning: Deprecated Resource (main.tf:291 kubernetes_persistent_volume_claim.home) Warning: Deprecated Resource (main.tf:321 kubernetes_deployment.main) ``` The provider has no version constraint, so every push floats to the newest release. v3.0 deprecated all un-suffixed resources; a future major removing them would break every workspace build on the next push, with no warning beyond these lines. ## Change 1. **Pin `hashicorp/kubernetes` to `~> 3.2`**, the version already in use, so behaviour doesn't change today. 2. **`kubernetes_deployment` → `kubernetes_deployment_v1`.** In the provider both names map to the same implementation (`resourceKubernetesDeploymentV1`, `kubernetes/provider.go:292-293`), so the schema is identical. The deployment is `count = start_count`: it is destroyed on every stop and created on every start, so the type change costs nothing beyond a normal restart. No data involved. ## Deliberately not changed: the home PVC `kubernetes_persistent_volume_claim.home` keeps its deprecation warning. It is the one persistent resource, and **renaming its type would make Terraform destroy and recreate every workspace's home volume**. A `moved` block can't help: cross-type moves need provider support, and v3.2.1's `MoveResourceState` is a no-op stub (`manifest/provider/server.go:115`). Migrating it safely needs `removed { lifecycle { destroy = false } }` + an `import` block, with the import made conditional so fresh workspaces (no PVC yet) don't fail. That deserves its own PR and a test against a throwaway workspace. The pin above keeps the deprecated type available until then. ## Validation `terraform init` + `terraform validate` with Terraform 1.14.5 (same as the Coder provisioner): valid, providers resolve to coder v2.18.0 / kubernetes v3.2.1 / http v3.6.2, only the intentional PVC warning left. Not plan/applied against a real workspace. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit

2026-09-30 08:13:34 +00:00

Pin the kubernetes provider and move the deployment to kubernetes_deployment_v1 ab267fb3e4

The kubernetes provider was unpinned, so each template push resolved to
the latest release (v3.2.1 today), which deprecates the un-suffixed
resources. Pin to ~> 3.2 so a future major can't remove them under us.

Switch the workspace deployment to kubernetes_deployment_v1 (same
implementation and schema in the provider). It is count = start_count,
so it is destroyed on every stop and recreated on start: the type
change costs nothing beyond a normal restart.

The home PVC stays on the deprecated type on purpose: the provider has
no cross-type state move, so renaming it would destroy and recreate
every workspace's home volume.

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