terraform icon indicating copy to clipboard operation
terraform copied to clipboard

azurerm_storage_account.virtual_network_subnet_ids needs to apply terraform twice to detect changes

Open Wiston999 opened this issue 1 year ago • 1 comments

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

Wiston999 avatar Jan 31 '24 10:01 Wiston999

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!

tombuildsstuff avatar May 23 '24 11:05 tombuildsstuff

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.

Wiston999 avatar Jul 01 '24 12:07 Wiston999

Hello,

This is actually an issue with the AzureRM provider, not something that Terraform core can change, nor a problem with the null provider. It may be an issue the AzureRM provider is not yet equipped to handle, but better resource planning is available in the Terraform Provider Framework when the resource type does get upgraded.

Thanks!

jbardin avatar Dec 13 '24 19:12 jbardin

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

github-actions[bot] avatar Jan 13 '25 02:01 github-actions[bot]