azurerm_storage_account.virtual_network_subnet_ids needs to apply terraform twice to detect changes

Wiston999 commented 8 months ago

Is there an existing issue for this?

[X] I have searched the existing issues

Community Note

Please vote on this issue by adding a :thumbsup: reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment and review the contribution guide to help.

Terraform Version

1.5.7

AzureRM Provider Version

v3.89.0

Affected Resource(s)/Data Source(s)

azurerm_storage_account

Terraform Configuration Files

variable "virtual_network_subnet_ids" {
  type    = list(string)
  default = []
}

resource "null_resource" "test" {
  triggers = {
    virtual_ids = join(",", var.virtual_network_subnet_ids)
  }

  provisioner "local-exec" {
    command = "echo ${self.triggers.virtual_ids}"
  }
}

resource "azurerm_storage_account" "storage_account" {
  name                            = "teststorageacc"
  location                        = "westeurope"
  resource_group_name             = "test-rg"
  account_tier                    = "Standard"
  account_replication_type        = "LRS"
  min_tls_version                 = "TLS1_2"
  enable_https_traffic_only       = true

  network_rules {
    default_action             = "Deny"
    bypass                     = ["AzureServices"]
    virtual_network_subnet_ids = var.virtual_network_subnet_ids
  }
}

Debug Output/Panic Output

# module.main-k8s-storage[0].null_resource.test must be replaced
-/+ resource "null_resource" "test" {
      ~ id       = "8225602398967497365" -> (known after apply)
      ~ triggers = { # forces replacement
          ~ "virtual_ids" = "/subscriptions/****/resourceGroups/****/providers/Microsoft.Network/virtualNetworks/****/subnets/****-public1,/subscriptions/****/resourceGroups/****/providers/Microsoft.Network/virtualNetworks/****/subnets/****-public2,/subscriptions/****/resourceGroups/****/providers/Microsoft.Network/virtualNetworks/****/subnets/****-public3,/subscriptions/****/resourceGroups/****/providers/Microsoft.Network/virtualNetworks/****/subnets/****-kubernetes-subnet" -> (known after apply)
        }
    }

# No changes for azurerm_storage_account.storage_account

Expected Behaviour

When variable for azurerm_storage_account.network_rules.virtual_network_subnet_ids changes, terraform plan and terraform apply should detect the change

Actual Behaviour

The change for azurerm_storage_account.network_rules.virtual_network_subnet_ids is detected when terraform apply is executed once. It is, the change is detected on the second terraform apply and not the first one.

Since null_resource.test resource detects the change in first terraform plan, it must be some issue with azurerm provider and not terraform core.

Steps to Reproduce

No response

Important Factoids

No response

References

No response

tombuildsstuff commented 4 months ago

hey @Wiston999

Taking a look through here this looks to be a bug in the null provider rather than something the Azure provider can resolve, since it should be highlighting that the triggers value has changes which affect downstream resources. As such I'm going to transfer this issue to the hashicorp/terraform repository, where someone from that the Terraform Core team (who maintain that Provider) should be able to take a look.

Thanks!

Wiston999 commented 3 months ago

Hello @tombuildsstuff .

I've been reviewing this issue in-depth. It turns out that I used null_resource as a simple way to demonstrate that null_resource detects the change in var.virtual_network_subnet_ids but azurerm_storage_account doesn't detect the change until a second apply is performed. Please do note that both null_resource and azurerm_storage_account use the same variable and that azurerm_storage_account is not a downstream resource of null_resource.

So I don't think this is a bug in null provider but in azurerm provider.

hashicorp / terraform