[Bug]: VPC Not Aware of IPAM Pool on Import

[lorengordon]

Terraform Core Version

1.7.4

AWS Provider Version

5.39.1

Affected Resource(s)

aws_vpc

Expected Behavior

I expect that if I import aws_vpc that its attributes should be accounted for in terraform state.

Actual Behavior

The VPC is imported, but there is no VPC IPAM pool information imported in state.

Relevant Error/Panic Output Snippet

No response

Terraform Configuration Files

kjenney/aws_vpc_ipam_test@main/main.tf - code to provision the VPC kjenney/aws_vpc_ipam_test@main/import/main.tf - code to re-provision it after the import

Steps to Reproduce

terraform init
terraform apply

Save vpc_id from Outputs of apply. Use this in the next step:

Example: VPC_ID="vpc-122523421532"

cd import
terraform init
terraform import aws_vpc.test $VPC_ID
terraform plan

Debug Output

# aws_vpc.test must be replaced
-/+ resource "aws_vpc" "test" {
      ~ arn                                  = "arn:aws:ec2:us-east-1:161101091064:vpc/vpc-0811a6d672906cfe6" -> (known after apply)
      - assign_generated_ipv6_cidr_block     = false -> null
      ~ cidr_block                           = "172.20.0.0/28" -> (known after apply)
      ~ default_network_acl_id               = "acl-0f2f3a3c06fef68b4" -> (known after apply)
      ~ default_route_table_id               = "rtb-0e32b49fd27dd51da" -> (known after apply)
      ~ default_security_group_id            = "sg-0312d9e8ec677f032" -> (known after apply)
      ~ dhcp_options_id                      = "dopt-5391c82b" -> (known after apply)
      ~ enable_dns_hostnames                 = false -> (known after apply)
      ~ enable_network_address_usage_metrics = false -> (known after apply)
      ~ id                                   = "vpc-0811a6d672906cfe6" -> (known after apply)
      + ipv4_ipam_pool_id                    = "ipam-pool-06fcc2048925bd472" # forces replacement
      + ipv4_netmask_length                  = 28 # forces replacement
      + ipv6_association_id                  = (known after apply)
      + ipv6_cidr_block                      = (known after apply)
      + ipv6_cidr_block_network_border_group = (known after apply)
      - ipv6_netmask_length                  = 0 -> null
      ~ main_route_table_id                  = "rtb-0e32b49fd27dd51da" -> (known after apply)
      ~ owner_id                             = "161101091064" -> (known after apply)
      - tags                                 = {} -> null
      ~ tags_all                             = {} -> (known after apply)
        # (2 unchanged attributes hidden)
    }

Plan: 1 to add, 0 to change, 1 to destroy.

Changes to Outputs:
  + pool_id = "ipam-pool-06fcc2048925bd472"

Panic Output

No response

Important Factoids

Reopening #34304. That issue was closed as expected behavior for import when the API does not return the values on read. But I contend that import also writes to the state, and it does know the correct values in this case since they are in the config. Therefore, import should write the values from the config that it does not get from the API read.

References

#34304

Would you like to implement a fix?

None

[github-actions[bot]]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[lorengordon]

@kjenney Fyi since you opened the prior issue. What do you think about the proposal to add the values from the config to the state on import?

[kjenney]

I'd love this, but I don't know how the CIDR association and the pool ID are linked via API after the VPC is provisioned.

[lorengordon]

They actually aren't linked directly via API, after the fact? My understanding is that you can destroy the IPAM, or delete the allocation, and the VPC itself is unaffected. And from the other direction, when you destroy the VPC, the IPAM resource discovery will "refresh" and realize the VPC is gone, and the allocation will be removed from the pool.