No resource schema found for local_file in Terraform Cloud

Terraform HCP Terraform
1

Hi,

I’ve been used Terraform Cloud for some time now, but I keep having issues when I delete a local_file resource from my scripts.

Scenario:

  1. I have the following resource:
resource "local_file" "values" {
  filename = "${path.module}/values.txt"
  content  = "Sample content"
}

The TFC runs works file and I can use the file.

  1. I now delete the local_file resource from my script and the run now fails with:
Error: Missing resource schema from provider
No resource schema found for local_file.

Any idea on how I could fix this issue?

Right now, I need to i) destroy the workspace ii) remove the local_file resource iii) run again.

Thanks,
Damien

1 Like
2

I am facing the same issue,
I am using terraform version 0.13, provider Terraform Registry v2.1.0 and having the following resource :

resource "local_file" "autonomous_data_warehouse_wallet_file" {
  content_base64 = XXXXXXXXXX
  filename       = XXXXXXXXXX
}

Now when I try to destroy this configuration using terraform 1.1.2 I get the following error on terraform destroy :

│ Error: Missing resource schema from provider
│ 
│ No resource schema found for local_file.

What is the fix?

Thanks,
Ashish

3

Hello, welcome to the forum both!

Before addressing the error, I just wanted to note something important about the nature of local_file and Terraform Cloud. The Terraform Cloud run environment is ephemeral, and the filesystem that you’re writing a file to is destroyed and recreated in a subsequent run. You can see this by leaving the resource block and running subsequent plans:

image
image653×694 47.2 KB

Depending on what you’re trying to do, you may not want to use this resource because of the nature of the remote run environment.

I have indeed recreated the error you found, though, and have determined it’s something due to the nature of provider schemas needing to be re-fetched for the remote run environment even as the local provider is no longer declared in the configuration (you removed it) and the ‘remote’ object (the literal file) has been deleted as expected.

If you really would like to continue using local_file with the ephemeral filesystem point I mentioned, a workaround for this is to declare the local provider explicitly for the runtime by adding something like this:

terraform {
  required_providers {
    local = {
      version = "~> 2.1"
    }
  }

Then the provider will be initialized and when you remove the resource block the plan will look like the following, which is expected:

image

Hope that helps!

1 Like
4

Thanks @chrisarcand
Adding the terraform block helped solve the issue

Although the issue is only with terraform v1.1, I am not getting any error with the earlier terraform versions even without adding the terraform block

5

Hi @ashishpm,

If the earlier versions you are talking about predate Terraform v1.0 then the reason for the change might be that earlier versions of Terraform didn’t record an object having been changed outside of Terraform, and therefore might not have needed the schema for that resource in this case because it would not have rendered the data from that object on-screen as part of reporting “No changes.”

It does seem like you’ve found an edge-case bug in modern Terraform where it seems to be making its decision about which schemas to load based only on the current configuration and possibly the refreshed state, and in particular not taking into account providers that are needed only to describe the previous run’s result when reporting the detected changes from “outside of Terraform”. Adding the required_providers block to the configuration allowed Terraform to see from the configuration that the provider was needed and thus avoided the problem.

If you have enough information to describe a reproduction case, and the other info requested in our bug report template, you could open a bug report issue about this and then we can look into it a bit deeper and see about making Terraform also include the schemas for providers in the “previous run state”. @chrisarcand if you still have your own reproduction handy then that would be helpful to include in a bug report!

(If anyone on this topic does open an bug report issue, please also share a link to it in this topic so that others who find this discussion can see any ongoing discussion about the bug. Thanks!)