azurerm_linux_web_app/azurerm_windows_web_app possible_outbound_ip_address_list cannot be dynamically used even if using depends_on

[cvallesi-kainos]

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

Terraform Version

1.2.9

AzureRM Provider Version

3.23.0

Affected Resource(s)/Data Source(s)

azurerm_linux_web_app, azurerm_windows_web_app, azurerm_postgresql_firewall_rule

Terraform Configuration Files

Here is a ready to go terraform configuration: https://github.com/cvallesi-kainos/azure-dynamic-app-service-ips-to-psql

Debug Output/Panic Output

2022-09-22T14:47:01.734+0100 [WARN]  Provider "registry.terraform.io/hashicorp/azurerm" produced an invalid plan for module.psql.azurerm_postgresql_server.main, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .create_mode: planned value cty.StringVal("Default") for a non-computed attribute
      - .auto_grow_enabled: planned value cty.True for a non-computed attribute
      - .geo_redundant_backup_enabled: planned value cty.False for a non-computed attribute
      - .ssl_minimal_tls_version_enforced: planned value cty.StringVal("TLS1_2") for a non-computed attribute
2022-09-22T14:47:01.735+0100 [ERROR] vertex "module.psql.azurerm_postgresql_firewall_rule.pw_app_service_ips" error: Invalid for_each argument
2022-09-22T14:47:01.735+0100 [ERROR] vertex "module.psql.azurerm_postgresql_firewall_rule.pw_app_service_ips (expand)" error: Invalid for_each argument
2022-09-22T14:47:01.735+0100 [INFO]  backend/local: plan operation completed
╷
│ Error: Invalid for_each argument
│
│   on ../modules/psql/networking.tf line 2, in resource "azurerm_postgresql_firewall_rule" "pw_app_service_ips":
│    2:   for_each = { for i, o in local.possible_outbound_ip_address_list: o => o }
│     ├────────────────
│     │ local.possible_outbound_ip_address_list is a list of string, known only after apply
│
│ The "for_each" map includes keys derived from resource attributes that cannot be determined until apply, and so Terraform cannot determine the full set
│ of keys that will identify the instances of this resource.
│
│ When working with unknown values in for_each, it's better to define the map keys statically in your configuration and place apply-time results only in
│ the map values.
│
│ Alternatively, you could use the -target planning option to first apply only the resources that the for_each value depends on, and then apply a second
│ time to fully converge.
╵
2022-09-22T14:47:01.739+0100 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-09-22T14:47:01.746+0100 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/hashicorp/azurerm/3.23.0/linux_amd64/terraform-provider-azurerm_v3.23.0_x5 pid=10473
2022-09-22T14:47:01.746+0100 [DEBUG] provider: plugin exited

Expected Behaviour

Considering that the configuration explicitly set a depends_on attribute, the plan and apply should go through and generate the firewall rules.

Actual Behaviour

The error clarify that because the IP list is not available before deployment, it cannot proceed.

Steps to Reproduce

1. Clone the repo: https://github.com/cvallesi-kainos/azure-dynamic-app-service-ips-to-psql
2. enter in terraform/env
3. run terraform init
4. run terraform plan
5. The error should show up

Important Factoids

No response

References

I realize that this is more a behaviour that should be addressed on the terraform level rather than azurerm but I thought to not escalate immediately as maybe there is some workaround that I'm not aware of.