How can I track down what is causing this change

Terraform
1

Hi team, we have this weird behaviour going on where a data source is being reread when we think it shouldn’t be.
A part of plan looks like this

 # module.backup_share.data.azurerm_subscription.current will be read during apply
  # (depends on a resource or a module with changes pending)
 <= data "azurerm_subscription" "current" {
      + display_name          = (known after apply)
      + id                    = (known after apply)
      + location_placement_id = (known after apply)
      + quota_id              = (known after apply)
      + spending_limit        = (known after apply)
      + state                 = (known after apply)
      + subscription_id       = (known after apply)
      + tags                  = (known after apply)
      + tenant_id             = (known after apply)
    }

I’m trying to locate what other resource “I think I know” but more importantly which value in the resource.

The code in general is (this is in a child module)
#Get Current Azure subscription
data “azurerm_subscription” “current” {
}

and it is adding tags to a resource group in the root module that is causing this to be reread.

I have run the plan with “Trace” turned on but this still didn’t provide this info

2

Hi @john.ward,

The reason shown in the plan output is depends on a resource or a module with changes pending. This means there is some dependency on a change in the configuration, outside of the arguments to the data source. These dependencies could be listed via depends_on in either the data source itself, or a containing module.

3

Hi @jbardin, this was turned out to be very old and seem to be a feature of Terraform, modules and the depends_on Meta-Argument.
Terraform document on feature :slight_smile:

The code that was causing the issue was some code that called this child module and that it had a depends on another module. The reason for the other depends was due that resources needed to be created first before the other module ran.

It seems the depends for the other module was causing this one to think it needed to reapplied and recheck the values for the current subscription.

Simple fix for us was to depend on the resource in the other child which was required to be build first and not the whole module.

Section of code causing issue

module "backup_share" {
  source               = "./modules/backup_share"
  backup_resource_type = "fs"
  backup_tier_letter   = "a"
  sa_id                = azurerm_storage_account.softwaredeployment_sa.id
  fs_name              = azurerm_storage_share.softwaredeployment.name
  depends_on           = [module.join_sa_to_rsv]  #here is the issue causing the bad plan

}

module "join_sa_to_rsv" {
  depends_on = [azurerm_backup_policy_file_share.policy1]
  source     = "./modules/join_sa_to_rsv"
  sa_id      = azurerm_storage_account.softwaredeployment_sa.id
}

We changed it to

module "backup_share" {
  source               = "./modules/backup_share"
  backup_resource_type = "fs"
  backup_tier_letter   = "a"
  sa_id                = azurerm_storage_account.softwaredeployment_sa.id
  fs_name              = azurerm_storage_share.softwaredeployment.name
  depends_on           = [module.join_sa_to_rsv.protect_container_sa] #replaced with the resource we needed built

}

module "join_sa_to_rsv" {
  depends_on = [azurerm_backup_policy_file_share.policy1]
  source     = "./modules/join_sa_to_rsv"
  sa_id      = azurerm_storage_account.softwaredeployment_sa.id
}

Hope this helps someone else.

4

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.