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.53k stars 9.52k forks source link

Unclear error message when mixing up "data" and "resource" blocks #34242

Open EugenKon opened 11 months ago

EugenKon commented 11 months ago

Terraform Version

I already upgraded couple of time, so I am not sure which version I used when reported the issue first time.

Terraform Configuration Files

-data "aws_route53_zone" "base_domain" {
+resource "aws_route53_zone" "base_domain" {
  name = "staging.example.com"

  delegation_set_id = aws_route53_delegation_set.ns_set.id
}

Debug Output

NA

Expected Behavior

Description

image

it is not clear here that I should replace data with resource:

-data "aws_route53_zone" "base_domain" {
+resource "aws_route53_zone" "base_domain" {
  name = "staging.example.com"

  delegation_set_id = aws_route53_delegation_set.ns_set.id
}

I expect something like you can not use delegation_set_id with "data"

Actual Behavior

It is not clear what error means.

Steps to Reproduce

Use specified type of resource.

Additional Context

No response

References

https://github.com/hashicorp/terraform-provider-aws/issues/33278

apparentlymart commented 11 months ago

Hi @EugenKon! Thanks for this feedback.

I think what you've suggested here would, in practice, be implemented like this:

If decoding the body of a resource block against the provider's schema for that managed resource type fails with any error, check whether there's a data resource type of the same name in the provider. If so, try decoding the block contents with the schema of that resource type. If that succeeds, it's possible that the author intended to use the data resource instead of the managed resource.

In that case then, Terraform could potentially add an extra paragraph to the end of the error message:

Did you intend to use the "aws_route53_zone" data source? If so, change
this declaration from a "resource" block to a "data" block.

The same logic could potentially work with the two resource modes swapped too: if it's a data block that fails, try looking for a managed resource type of the same name and try decoding with that.

There are lots of different specific error messages that could result from selecting the wrong resource type, which is why I framed the above as behavior implemented in response to any error related to the body of the block. It's also possible that variations of this mistake could lead to multiple error messages, in which case I suppose we'd need to annotate all of them with the extra paragraph if the heuristic matches.

While considering this, we might also consider another variation: if there's another resource type in the provider whose name has a small edit distance from the one the author specified, we could try decoding against that one and if successful produce an error message suggesting the other resource type. As far as Terraform itself is concerned, the mistake of selecting a managed resource type instead of a data resource type is essentially the same as choosing the wrong resource type within a particular resource mode.