terraform-provider-ibm
terraform-provider-ibm copied to clipboard
ibm_is_subnet change routing table to null does not make the subnet dirty
sources: https://github.com/powellquiring/tfbugs/tree/master/bug-subnet-routing-table
Expected changing the subnet to null would be deleted then added. Actual no changes
resource:
resource "ibm_is_subnet" "subnets" {
name = var.basename
vpc = ibm_is_vpc.vpc.id
zone = local.zones[0]
total_ipv4_address_count = 256
resource_group = data.ibm_resource_group.group.id
# terraform apply then switch the comments on these two lines:
routing_table = ibm_is_vpc_routing_table.location.routing_table
# routing_table = null
}
- initial state, apply:
routing_table = ibm_is_vpc_routing_table.location.routing_table
# routing_table = null
- change state, then apply
# routing_table = ibm_is_vpc_routing_table.location.routing_table
routing_table = null
results:
➜ bug-subnet-routing-table git:(master) ✗ tfa
ibm_is_vpc.vpc: Refreshing state... [id=r006-42cbc2eb-120b-462c-8b64-b03ea860a876]
ibm_is_vpc_routing_table.location: Refreshing state... [id=r006-42cbc2eb-120b-462c-8b64-b03ea860a876/r006-eb9d3823-4884-49aa-b40a-2d627e42988a]
ibm_is_subnet.subnets: Refreshing state... [id=0717-46bde1f2-4b11-408b-b75f-e4ae075a60db]
No changes. Your infrastructure matches the configuration.
Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are
needed.
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
@powellquiring Subnet does not allow removal of a routing table, you should be able to replace it with a new one.
This should be a "force new" attribute of the subnet.
Agreed.
@powellquiring
Here is my analysis,
Terraform doesn't detect difference when null value is passed to string argument, Instead you can try passing "" or " ".
force new cannot be set to true as we can update routing table and also If unspecified when creating subnet , the default routing table will be attached to it.
From my knowledge you want subnet to be referenced back to default routing table, you can do that so by passing ibm_is_vpc.vpc.default_routing_table to routing_table field. https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/is_vpc
Do let us know if you have any concerns
Thanks
I really want this to work:
resource "ibm_is_subnet" "subnets" {
name = var.basename
vpc = ibm_is_vpc.vpc.id
zone = local.zones[0]
total_ipv4_address_count = 256
resource_group = data.ibm_resource_group.group.id
# Step 1: terraform apply
# Step 2: comment out the line below, and terraform apply again.
routing_table = ibm_is_vpc_routing_table.location.routing_table
}
Step 2 results in no changes
layer1 $ tfa
ibm_is_vpc.cloud: Refreshing state... [id=r006-dda6e28b-4ab3-4bc2-b980-6a7f5b85dd80]
ibm_is_vpc_address_prefix.name: Refreshing state... [id=r006-dda6e28b-4ab3-4bc2-b980-6a7f5b85dd80/r006-5397abe7-039c-46ba-85b3-05db6dc48209]
ibm_is_vpc_routing_table.example: Refreshing state... [id=r006-dda6e28b-4ab3-4bc2-b980-6a7f5b85dd80/r006-9216c607-0eab-4a66-8bbd-6be374d1c9fd]
ibm_is_subnet.name: Refreshing state... [id=0717-3d4aa7e9-95cf-4659-975a-ccd94c41521b]
No changes. Your infrastructure matches the configuration.
Terraform has compared your real infrastructure against your configuration and found no differences, so no
changes are needed.
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
Outputs:
basename = "bplocal00"
region = "us-south"
resource_group_id = "6eb17cb9398542c09783bf8c95190dd6"
vpc_id = "r006-dda6e28b-4ab3-4bc2-b980-6a7f5b85dd80"
Expected: the routing_table would be set to the ibm_is_vpc.vpc default routing table.
Hi @powellquiring,
If routing_table field is empty and we assign default routing table then update would be shown in every next terraform apply, hence we cann't assign it to default routing table. Instead if you want subnet to be referenced back to default routing table, you can do that so by passing ibm_is_vpc.vpc.default_routing_table to routing_table field.
Expected: A terraform configuration is an unambiguous specification of the desired state. Actual: The subnet.routing_table value is going to be different depending on the configuration history. My staging and production configurations could have the same terraform files but have a different configuration.
It would be better to make the subnet.routing_table a required argument.