migrate-v2-to-v3

Migrates kube-hetzner Terraform roots from module v2.x to v3.x with plan safety gates.

3.9k|563|Updated Jul 30, 2021
One-click install
npx skills add https://github.com/mysticaltech/terraform-hcloud-kube-hetzner --skill migrate-v2-to-v3
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: migrate-v2-to-v3
Source: https://github.com/mysticaltech/terraform-hcloud-kube-hetzner/tree/main/.claude/skills/migrate-v2-to-v3
Command: npx skills add https://github.com/mysticaltech/terraform-hcloud-kube-hetzner --skill migrate-v2-to-v3

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Upgrading a live kube-hetzner Kubernetes cluster from Terraform module v2.x to v3.x involves renamed variables, inverted booleans, silent default changes, and the risk of Terraform destroying production Hetzner infrastructure. This Skill guides the migration so validation failures become actionable and destructive plan actions are caught before apply.

Core Features & Use Cases

  • Configuration Rewriting: Maps v2 inputs to v3 using MIGRATION.md, including renames like k3s_token to cluster_token, inverted booleans like disable_selinux to enable_selinux, and replacements like existing_network_id to existing_network.
  • Static and Plan Audits: Runs scripts/v2_to_v3_migration_assistant.py against the Terraform root and the plan JSON to detect v2-only inputs and risky changes.
  • Protected-Infrastructure Gate: Uses a jq filter over terraform show -json output to block any delete or replace action on hcloud_server, hcloud_network, hcloud_load_balancer, hcloud_volume, and other critical resource types.
  • Use Case: An operator with a production k3s cluster on Hetzner Cloud wants to upgrade the module to v3.2.0 without recreating servers; the Skill backs up state, rewrites the root, validates with Terraform and OpenTofu, and produces a migration report before any apply.

Quick Start

Migrate my kube-hetzner Terraform root in the current directory from module v2 to v3 and show me the plan safety report before applying anything.

Frequently Asked Questions about migrate-v2-to-v3

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I migrate kube-hetzner from v2 to v3?

Back up Terraform state, rewrite v2 inputs using the MIGRATION.md variable map, run terraform init -upgrade and validate, then review a saved plan. Apply only after the protected-resource gate shows zero deletes on hcloud_server, network, load balancer, and volume resources.

What changed in kube-hetzner v3 variable names?

v3 renames distribution-neutral inputs like k3s_token to cluster_token, inverts negative booleans such as disable_selinux to enable_selinux, and replaces existing_network_id with an existing_network object. MIGRATION.md contains the complete old-to-new variable map.

Does kube-hetzner v3 work with OpenTofu?

Yes, the migration workflow validates the root with both terraform validate and a separate OpenTofu init and validate pass in a temporary directory. This confirms the configuration loads under both toolchains before planning.

Why does my v3 upgrade plan show resource replacements?

Replacements of hcloud_server, network, subnet, load balancer, primary IP, placement group, volume, or firewall resources are blockers, not normal upgrade actions. They usually indicate wrong variable mappings, reordered nodepools, or subnet mode changes that must be fixed before apply.

What k3s channel should I set when upgrading to v3?

v2 defaulted k3s_channel to v1.33 while v3 defaults to stable with automatic upgrades enabled. Before the first v3 apply, explicitly pin k3s_version, set k3s_channel to v1.33 to preserve the v2 minor channel, or consciously accept following stable.

When should I choose blue/green instead of in-place v3 upgrade?

Prefer blue/green for custom network, private-only, Robot/vSwitch, or multinetwork clusters when the in-place plan is not clearly safe. Also use it when adding new v3 features like Cilium Gateway API or Tailscale transport rather than combining them with the base migration.