`Move Resource State Not Supported` when migrating to 3.0.0

[slenky]

Description

We were using the kubernetes_namespace resource in our modules, and during an upgrade to 3.0.0 I tried using a moved block so that we wouldn’t have to recreate or import namespaces. Instead, I’m getting the following error:

Error: Move Resource State Not Supported
The "kubernetes_namespace_v1" resource type does not support moving resource
state across resource types.

The same issue occurs for kubernetes_cluster_role_binding_v1 and kubernetes_secret_v1.

Potential Terraform Configuration

resource "kubernetes_namespace_v1" "this" {
  metadata {
    name = "foo"
  }
}

moved {
  from = kubernetes_namespace.this
  to     = kubernetes_namespace_v1.this
}

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[sidick]

This is documented at https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs/guides/versioned-resources#how-can-i-move-a-resource-without-a-version-to-its-versioned-resource-name but having a way to do this without command line commands would be way better

[slenky]

Yes, but we have thousands of resources so I would certainly prefer a declarative way to migrate :) According to the Terraform documentations it is something that could be implemented on the provider side:

Each resource type has a separate schema so objects of different types are not typically compatible. You can always use the moved block to change the name of a resource, but some providers also let you change an object from one resource type to another. Refer to the provider documentation for details on which resources can move between types.

[zhimsel]

I'll add my vote to allowing this.

If it's removable/importable without changes, then there should be no reason not allow a moved {} block to do this for you. It's functionally the same. Presumably, Terraform/Tofu would do a refresh operation prior to planning the resource (and after "moving" it). I'm not an expert on Terraform internals, but I imagine that would work, no?

[nwsparks]

deprecating the unversioned resource without providing this functionality is a bizarre and incredibly cumbersome change to force upon users.

if the maintainers are unwilling to allow the moved blocks to work, then they should reconsider what their intent here is with the deprecation. this leads to future problems if we ever need to do more migrations to v2, v3, etc. it would be interesting to see the rationale for why it was decided to go this direction.

[ryanisnan]

I get it, naming things is hard. Naming things that get stored in state, and then having to change them is harder. And then distributing that problem across thousands or millions of users is even harder. Forcing users to do imperative state surgery here is not the way.

How can I help make this happen?

[Jasper-Ben]

We currently have 500+ affected kubernetes resources. Expecting users to migrate from unversioned to versioned resources on a per-resource basis by removing and re-importing it from the tf state is wild. Surely there must be a better way to address this?

[Infinoid]

Same. We'll stick with the v2.x provider until a cleaner migration path is available.

[gws]

I agree it'd be really helpful to see support for moved, but for anyone looking for a declarative migration workaround and they have control over the root module, it looks doable with a combination of removed and import blocks:

## migrate.tf

removed {
  from = kubernetes_secret.foo

  ## Ensure we just remove from state, not the resource itself
  lifecycle {
    destroy = false
  }
}

import {
  id = "kube-namespace/foo"
  to = kubernetes_secret_v1.foo
}

It's definitely more cumbersome than moved but hope it helps someone.

[nwsparks]

Can that be done in a module? Moved can be declared once in a module. I would assume Import needs to be declared in each state that is calling the module, but if not then this would help, otherwise it's the same amount of work as the CLI commands, or perhaps more work.

The root of this issue is that this is poorly thought out design even if they do support moved blocks. Having to deal with this anytime they change the version is too cumbersome.

[wedge-jarrad]

@gws the "removed" and "import" strategy was the first thing I tried (because I didn't realize "moved" existed). It works well if the module has already been applied and there are existing resources. But the import statement fails if it's the first run of the module. That means that I can't release a new version of the module which includes this logic because it won't work for new consumers of the module.

Having the "moved" block in the module works for first time use, but trying it for an existing resource is what led me here to this issue.

[stevehipwell]

I'm still trying to understand why this flagship official TF provider didn't implement the State Move functionality so we could simply use a moved block? Maybe because it's still using the (long time) legacy Plugin SDK v2 instead of the fully supported Plugin Framework!?

Come on Hashicorp switching to the framework is long overdue and should have been the first item on the list for the v3 release if you were deprecating all non _v1 resources. If only there was a way to make large but predictable changes easily...

[stephenmelrose]

I would like to +1 this feature. We too have a lot of workspaces/resources and using moved would be so much easier than having to use command line tools. So now we're stuck with deprecation warnings we can't easily resolve.

[gss2002]

This is beyond necessary the fact that this is non-existant is a HUGE miss by this provider