Avoid unnecessary data lookup deferral

[industrialzombie]

Terraform Version

1.5.4

Use Cases

When one resource that is managed by Terraform has dependent resources that are not managed by Terraform, it is sometimes necessary to use a data resource to retrieve the calculated attributes of the dependent resources.

Currently any planned changes to the resource that is managed by Terraform will cause the data resource to be deferred to apply time. Even if the properties that are changing are not referenced by the data resource.

For any downstream resources that depend on the outputs of the data resource, they are forced plan pessimistically (usually a destroy and recreate).

This could be avoided if the logic that decides whether a data resource must be deferred was updated to look for any planned changes in each specific input, rather than considering resources as a whole.

Example scenario

A concrete scenario where we've encountered this was with the AWS provider. A planned change to a Transit Gateway prefix list was causing a planned drop and recreate of other TGW resources.

The same scenario exists with the VPC endpoint resource, which requires a separate data resource to retrieve the private ID for an interface endpoint.

In general, this is not a problem with any specific provider, but occurs any time the following setup is needed (where creating a "thing_a" will cause a "thing_b" to be automatically created)

resource "foo_thing_a" "a" {
  some_property = "foo"
}

data "foo_thing_b" "b" {
  id = foo_thing_a.a.id
}

resource "foo_thing_c" "c" {
  some_property = data.foo_thing_b.b.some_property
}

In the above scenario, a change to "some_property" guarantees the deferral of the data resource, which may cause "c" to be destroyed and recreated. This happens even if Terraform could work out that the ID of "a" wasn't planned to change.

Attempted Solutions

There are 3 workarounds for this that I know of.

1 - Live with it

Sometimes it's harmless to have downstream resources be recreated. While it results in a messy plan, it may not cause any problems.

2 - Use custom diff logic

Custom diff logic in the provider resources can be used to override the default behavior. AWS tried this and found it was not a good option (they rolled back the change).

3 - Add extra outputs to the resources to avoid the data lookup

Sometimes using a data resource can be avoided by adding the outputs to the main resource. This makes sense in certain circumstances (and was ultimately what AWS did) but it breaks encapsulation and complicates the provider.

Proposal

I propose that the core Terraform logic is updated so that data lookup deferral only happens if the specific properties upon which the data resource depends are unknown until apply time.

resource "foo_thing_a" "a" {
  property1 = "p1" # Changing this causes a possible change to "output1"
  property2 = "p2" # Changing this doesn't cause a change to "output1"
}

data "foo_thing_b" "b" {
  id = foo_thing_a.a.output1
}

In the above setup, if the configuration has a change to proprety1, the schema would indicate that output1 may change. When the data resource is considered, it has to be be deferred.

However, if the configuration only has a change to property2, then the schema would indicate that output1 will not change. The data resource can then be safely executed at plan time.

References

Here are some examples of AWS grappling with this issue and trying the various workarounds.

hashicorp/terraform-provider-aws#30085 (demonstrates the side effect)
hashicorp/terraform-provider-aws#41292 (workaround 2)
hashicorp/terraform-provider-aws#43405 (workaround 2)
hashicorp/terraform-provider-aws#43436 (workaround 3)
hashicorp/terraform-provider-aws#43706 (my suggestion to AWS to rollback workaround 2)

[jbardin]

Hi @industrialzombie,

This is a known inconsistency with data resources in Terraform, which was only maintained for backwards compatibility. There were too many configurations depending on the way implicit dependencies works, and not enough time to deprecate and migrate all those configurations. The workaround is to indirect the reference between the data source and the managed resource.

resource "foo_thing_a" "a" {
  some_property = "foo"
}

locals {
  foo_thing_a_id = foo_thing_a.a.id
}

data "foo_thing_b" "b" {
  id = local.foo_thing_a_id
}

resource "foo_thing_c" "c" {
  some_property = data.foo_thing_b.b.some_property
}

This disconnects the implicit depends_on from the data source to the resource, and then planning can proceed only based on whether the data source's configuration is entirely known or not. See also #32042 and #30083 among others.

[industrialzombie]

Hey thanks @jbardin,

I wasn't aware of this workaround - thank you for documenting it here for anyone facing the same issue in the future!

Speaking of documentation, this workaround used to be clearly documented (up to v1.11) but seems to have been reworded in the documentation (v1.12 onwards).

In order to ensure that data sources are accessing the most up to date information possible
in a wide variety of use cases, arguments directly referencing managed resources are treated
the same as if the resource was listed in depends_on. This behavior can be avoided when
desired by indirectly referencing the managed resource values through a local value, unless
the data resource itself has [custom conditions](https://developer.hashicorp.com/terraform/language/v1.11.x/data-sources#custom-condition-checks).

https://developer.hashicorp.com/terraform/language/v1.11.x/data-sources#data-resource-dependencies

Terraform correctly detects dependencies in your configuration, even when indirectly reference
a Terraform-managed resource values through a local value.

https://developer.hashicorp.com/terraform/language/v1.12.x/data-sources#dependencies

I would be interested to know if anything changed in the provider; and if not, whether this workaround could be added back into the documentation.

[jbardin]

Thanks @industrialzombie! It is strange the docs were changed. I'll let the docs team know