Unable to remove resource attribute that was provisioned with Terraform

I am working with a GCP Cloud Composer resource and added in a dynamic block to create an attribute for the resource to set allowed_ip_ranges which can be used as an IP filter for accessing the Apache Airflow Web UI.

I was able to get the allowed ranges setup and can update them in place to new values also.

If I attempt to pass in a blank list I am expecting the IP address(es) to be removed as attributes for the resource but Terraform seems to think that no changes are needed.

There is probably something wrong in my code but I am not sure what exactly I would need to do. Does it involve adding in a conditional expression to the for_each loop in the dynamic block?
Child module main.tf

    web_server_network_access_control {
      dynamic "allowed_ip_range" {
        for_each = var.allowed_ip_range
        content {
          value       = allowed_ip_range.value["value"]
          description = allowed_ip_range.value["description"]
        }
      }
    }

Child module variables.tf

variable "allowed_ip_range" {
  description = "The IP ranges which are allowed to access the Apache Airflow Web Server UI."
  type        = list(map(string))
  default     = []
}

Parent module terraform.tfvars

allowed_ip_range                 = [
    {
    value = "11.0.0.2/32"
    description = "Test dynamic block 1"
    },
]

Hi @rk92,

Unfortunately the provider seems to treat this block type in a special way where if you don’t specify any nested blocks of that type at all then the provider understands that as a request to keep whatever objects already exist, rather than to remove those existing objects.

Since there’s an ambiguity in the provider’s model here I don’t think there is any way to explicitly specify that you want to have no ranges at all. The only way to get that effect, I think, would be to manually delete the existing objects, at which point “keep whatever objects already exist” would mean “keep the absence of objects”, because there would be no objects that exist.

Another workaround to consider here could be to try using either a match-everything or match-nothing IP range, if the remote system allows such a thing. "0.0.0.0/0" would match everything, and "255.255.255.255/32" would match nothing (because that’s not a valid host address), but I don’t know if the remote system has any restrictions on what sorts of patterns you can use.

In order to support your use-case this provider would need to separate the idea of “keep whatever objects already exist” from the idea of having zero objects, but I assume that it’s built the way it is for historical reasons of backwards compatibility.

@apparentlymart Thanks for the reply, that makes more sense as to why the blank list didn’t work the way I intended it to. I will try out the other IP address ranges you suggested.

My workaround was to manually delete the whitelisted IPs in the GCP console and then re-run a terraform apply while making sure my tfvars had a blank list. This caused the state file to be updated with those values removed.