How to remove provider.template from remote state

I’m trying to upgrade to Terraform 0.13 on an Apple M1 machine, and it has been an absolute nightmare.

We are currently on Terraform 0.12, and when I got my new M1 machine I had to build Terraform and the template provider from source to get 0.12 to work. However, in Terraform 0.13 when I build Terraform and the template provider from source and install it locally, Terraform 0.13 will not recognize the locally installed template provider no matter what I do…that’s a separate issue.

So my thought process was to remove the use of the deprecated template provider from our Terraform configs so I can avoid it altogether when upgrading to 0.13. I went through the exercise of removing all uses of template provider in our configs, and now the only place I see the template provider when running terraform providers is from the remote state. For example:

└── module.zookeeper
    ├── provider.aws (inherited)
    └── provider.template (from state) <---- HERE

And sure enough it is still in the remote state file:

    {
      "module": "module.zookeeper",
      "mode": "data",
      "type": "template_file",
      "name": "user_data",
      "provider": "provider.template",

However, when I run a terraform plan for this module it says there’s nothing to do.

So my question is, how do I remove these template provider entries from my remote state so that Terraform will stop seeing the template provider as a dependency in my project?

1 Like

You could manually remove it from state with terraform state rm module.zookeeper.data.template_file.user_data

1 Like

Thanks for replying @stuart-c. I could certainly do that, but I’m curious as to why Terraform doesn’t determine for itself that I removed that data "template_file" "user_data" {} template file data source from the configuration, and thus it needs to be removed from the remote state.

Terraform won’t change the state file unless you run one of the commands which can do so - so an apply or refresh. Have you tried running either of those?

1 Like

@stuart-c did not run apply, as I indicated above that when I ran terraform plan it indicated there were no changes to be applied.

Hi @bploetz,

I just tried this out with Terraform v1.1.2 (because that’s what I happen to have installed right now) and saw it behave in the way you expected – terraform apply removed the no-longer-needed data resource automatically from the state.

Therefore I have to assume what you found here is a quirk/bug that was fixed in a later version. To work around it I’d make the same suggestion @stuart-c did.

Another possible workaround would be to run terraform refresh to ask Terraform to resynchronize the state without changing anything else, which could therefore avoid the problem you encountered here where Terraform sees no change required and therefore stops before saving the updated state, because you’d effectively be running the first step of the plan/apply process (getting the state up-to-date) without the other steps.

3 Likes

Yes terraform refresh worked exactly as intended! Thank you @apparentlymart :man_dancing:

but you can’t run terraform refresh if you have dependency

│ Error: Inconsistent dependency lock file
│
│ The following dependency selections recorded in the lock file are inconsistent with the current configuration:
│   - provider registry.terraform.io/cyrilgdn/postgresql: required by this configuration but no version is selected
│   - provider registry.terraform.io/hashicorp/aws: required by this configuration but no version is selected
│
│ To make the initial dependency selections that will initialize the dependency lock file, run:
│   terraform init
╵

I fixed this by manually editing state file and removing template. I hope it this helps some another poor soul here