hashicorp / terraform

Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
https://www.terraform.io/
Other
42.66k stars 9.55k forks source link

No provider config schema available message for builtin provider should not be labelled ERROR in output #34207

Open thewileyriley opened 12 months ago

thewileyriley commented 12 months ago

Terraform Version

1.6.3

Terraform Configuration Files

data "terraform_remote_state" "this" {
  backend = "local"
    config = {
    path = "/path/to/pre-existing/terraform.tfstate"
  }
}

Debug Output

2023-11-08T14:34:04.205+0200 [DEBUG] ProviderTransformer: "data.terraform_remote_state.this" (*terraform.NodeValidatableResource) needs provider["terraform.io/builtin/terraform"] 2023-11-08T14:34:04.205+0200 [ERROR] AttachSchemaTransformer: No provider config schema available for provider["terraform.io/builtin/terraform"] 2023-11-08T14:34:04.210+0200 [DEBUG] ReferenceTransformer: "data.terraform_remote_state.this" references: []

Expected Behavior

[ERROR] AttachSchemaTransformer: No provider config schema available for provider["terraform.io/builtin/terraform"]

The above message should:

  1. Be clearer. There is a provider - it is just built-in and not explicitly defined.
  2. The [ERROR] label should be [DEBUG]. If it is left as [ERROR], it makes it much more difficult for a log filter to actually differentiate it from real errors.

Actual Behavior

  1. There is a misleading error message.
  2. The message is erroneously labelled as [ERROR].

Steps to Reproduce

  1. export TF_LOG=DEBUG
  2. terraform init
  3. terraform plan

Additional Context

No response

References

No response

jbardin commented 12 months ago

Hi @thewileyriley,

Thanks for filing the issue! The log message is correct in most cases, except it does produce an erroneous message for the terraform provider. Since the log output is targeted at the developers (the "error" would usually be in the code), it hasn't yet been handled as a special case. It's probably more correct to just make sure the internal provider has an empty schema even though it's not used.

thewileyriley commented 12 months ago

@jbardin Thanks for your feedback. What is an issue for me is that I am using an ADO Terraform task https://github.com/microsoft/azure-pipelines-terraform/tree/main/Tasks/TerraformTask/TerraformTaskV4 which filters the debug log and prints anything with the [ERROR] label in the Terraform log to stdout in red. It is not something the bothers me particularly, however - it does raise questions from other people that use the pipeline and it also makes the output look less clean.

Is it possible to change the label so we can keep the log output clean?

jbardin commented 12 months ago

The label is probably not going to change, since it would be an error in most cases, but we can probably avoid this situation with the terraform provider in a future release. I'm not sure what the reasoning for the log output in that task is, any errors (or even warnings) which are actionable by a user will be output in the normal diagnostics. The logs are targeted at developers, however if a user is having a problem the warn level is often most useful as it will display certain provider problems which could result in confusing behaviors.

delaosa commented 8 months ago

Same issue here but in my case using a "terraform_data" resource.

Code:

resource "terraform_data" "product_version" { input = var.product_version }

Error:

2024-02-14T12:18:42.213Z [ERROR] AttachSchemaTransformer: No provider config schema available for provider["terraform.io/builtin/terraform"]

hitsthings commented 2 months ago

Terraform noob here. Am I right in reading this issue and thinking that there is nothing actionable for me when I see this output?

I am hearing that this is targeted at "the developers" who in this case would be Terraform itself? And the solution is to "make sure the internal provider has an empty schema" which is something that would happen within Terraform and not something I would do as a user?

Thanks for any clarification.

crw commented 2 months ago

@hitsthings Correct. The message is meant for developers of providers for Terraform. So for example the team that develops the AWS provider or Azure provider (etc) must define a schema for their providers. If you were developing a new provider for the foo cloud service and you failed to define a schema, this error would alert you to that before you published the provider.

In the case of the terraform provider, it purposefully does not have a schema, which is causing this error. @jbardin is saying the developers of that provider should add an empty schema to that provider, to get rid of this error.

yitzhtal commented 2 months ago

Facing the same issue here.

crw commented 2 months ago

I forgot to add the customary:

Thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!