hashicorp / terraform-provider-azurerm

Terraform provider for Azure Resource Manager
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs
Mozilla Public License 2.0
4.6k stars 4.64k forks source link

`data` sources generally always show changes #27441

Open Freyert opened 1 month ago

Freyert commented 1 month ago

Is there an existing issue for this?

Community Note

Terraform Version

1.4.6

AzureRM Provider Version

3.116.0

Affected Resource(s)/Data Source(s)

data.azurerm_subnet,data.azurerm_client_config

Terraform Configuration Files

It's extremely basic usage of both of these resources:

data "azurerm_client_config" "current" {}

resource "mongodbatlas_network_peering" "azure" {
  project_id            = mongodbatlas_project.azure.id
  container_id          = mongodbatlas_network_container.azure.container_id
  provider_name         = local.atlas_cloud_provider
  azure_directory_id    = data.azurerm_client_config.current.tenant_id
  azure_subscription_id = data.azurerm_client_config.current.subscription_id
  resource_group_name   = var.resource_group_name
  vnet_name             = var.virtual_network_name
}

### Debug Output/Panic Output

```shell
Nothing interesting. I've walked it in the debugger and everything works fine. It's just that the for some reason the existing state isn't referenced/loaded (I think).

Expected Behaviour

When we run plans subsequent times the data source should not trigger recreation for downstream resources.

Actual Behaviour

Any resource that references the data source is forced into a change. As you can see it causes some fairly serious resources to change.

I've noticed you all do some interesting things that I could conceive of as causing this sort of unexpected behavior, but I haven't found direct proof. Specifically I think this might have to do with the fact that you all have made a vendored shim of the pluginsdk.

  # (depends on a resource or a module with changes pending)
 # there is no dependency here. It's just empty.
 <= data "azurerm_client_config" "current" {
      + client_id       = (known after apply)
      + id              = (known after apply)
      + object_id       = (known after apply)
      + subscription_id = (known after apply)
      + tenant_id       = (known after apply)
    }
  # module.atlas_projects["X"].mongodbatlas_network_peering.azure must be replaced
-/+ resource "mongodbatlas_network_peering" "azure" {
      + accepter_region_name   = (known after apply)
      ~ atlas_cidr_block       = "192.168.X.0/22" -> (known after apply)
      + atlas_gcp_project_id   = (known after apply)
      ~ atlas_id               = "XXXXXX" -> (known after apply)
      + atlas_vpc_name         = (known after apply)
      + aws_account_id         = (known after apply)
      ~ azure_directory_id     = "XXXXXXX" # forces replacement -> (known after apply) # forces replacement
      ~ azure_subscription_id  = "XXXXXXX" # forces replacement -> (known after apply) # forces replacement
      + connection_id          = (known after apply)
      + error_message          = (known after apply)
      + error_state            = (known after apply)
      + error_state_name       = (known after apply)
      + gcp_project_id         = (known after apply)
      ~ id                     = "XXXXXXXX" -> (known after apply)
      + network_name           = (known after apply)
      ~ peer_id                = "XXXXXXXX" -> (known after apply)
      + route_table_cidr_block = (known after apply)
      ~ status                 = "AVAILABLE" -> (known after apply)
      + status_name            = (known after apply)
      + vpc_id                 = (known after apply)
        # (5 unchanged attributes hidden)
    }

Steps to Reproduce

No response

Important Factoids

If you can point me to some useful code points I can use the debugger to explore more.

References

https://github.com/hashicorp/terraform-provider-azurerm/issues/20303 https://github.com/hashicorp/terraform/issues/29716 https://discuss.hashicorp.com/t/data-sources-forcing-replacement-even-though-nothing-has-changed/46452/2

Freyert commented 1 month ago

I just moved the data source out of the module and it seemed to fix this.