I have multiple IP whitelist resources set up for the same project, but they seem to behave inconsistently.
Behaviour: Initial terraform apply succeeds; subsequent apply's seem to get increasingly confused about what the whitelists are. It seems that it wasn't able to correctly link the resources to their representation from Atlas.
$ terraform apply
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
+ mongodbatlas_ip_whitelist.server
id: <computed>
cidr_block: "13.x.x.x/32"
comment: "Access for the dedicated server"
group: "5aba24a197019902d2e2698c"
ip_address: <computed>
+ mongodbatlas_ip_whitelist.subnet_a
id: <computed>
cidr_block: "10.1.100.0/24"
comment: "Access from Subnet A"
group: "5aba24a197019902d2e2698c"
ip_address: <computed>
+ mongodbatlas_ip_whitelist.subnet_b
id: <computed>
cidr_block: "10.1.101.0/24"
comment: "Access from Subnet B"
group: "5aba24a197019902d2e2698c"
ip_address: <computed>
Plan: 3 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
mongodbatlas_ip_whitelist.subnet_b: Creating...
cidr_block: "" => "10.1.101.0/24"
comment: "" => "Access from Subnet B"
group: "" => "5aba24a197019902d2e2698c"
ip_address: "" => "<computed>"
mongodbatlas_ip_whitelist.subnet_a: Creating...
cidr_block: "" => "10.1.100.0/24"
comment: "" => "Access from Subnet A"
group: "" => "5aba24a197019902d2e2698c"
ip_address: "" => "<computed>"
mongodbatlas_ip_whitelist.server: Creating...
cidr_block: "" => "13.x.x.x/32"
comment: "" => "Access for the dedicated server"
group: "" => "5aba24a197019902d2e2698c"
ip_address: "" => "<computed>"
mongodbatlas_ip_whitelist.server: Creation complete after 3s (ID: 13.211.169.74/32)
mongodbatlas_ip_whitelist.subnet_a: Creation complete after 3s (ID: 10.1.100.0/24)
mongodbatlas_ip_whitelist.subnet_b: Creation complete after 3s (ID: 10.1.100.0/24)
Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
Terraform apply run 2 (no changes to templates):
$ terraform apply
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement
Terraform will perform the following actions:
-/+ mongodbatlas_ip_whitelist.subnet_b (new resource required)
id: "10.1.100.0/24" => <computed> (forces new resource)
cidr_block: "10.1.100.0/24" => "10.1.101.0/24" (forces new resource)
comment: "Access from Subnet A" => "Access from Subnet B"
group: "5aba24a197019902d2e2698c" => "5aba24a197019902d2e2698c"
ip_address: "" => <computed>
Plan: 1 to add, 0 to change, 1 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
mongodbatlas_ip_whitelist.subnet_b: Destroying... (ID: 10.1.100.0/24)
mongodbatlas_ip_whitelist.subnet_b: Destruction complete after 2s
mongodbatlas_ip_whitelist.subnet_b: Creating...
cidr_block: "" => "10.1.101.0/24"
comment: "" => "Access from Subnet B"
group: "" => "5aba24a197019902d2e2698c"
ip_address: "" => "<computed>"
mongodbatlas_ip_whitelist.subnet_b: Creation complete after 3s (ID: 13.211.169.74/32)
Apply complete! Resources: 1 added, 0 changed, 1 destroyed.
Terraform apply run 3 (still no changes to templates):
$ terraform apply
Error: Error refreshing state: 1 error(s) occurred:
* mongodbatlas_ip_whitelist.subnet_a: 1 error(s) occurred:
* mongodbatlas_ip_whitelist.subnet_a: mongodbatlas_ip_whitelist.subnet_a: Error reading MongoDB Project IP Whitelist 10.1.100.0/24: MongoDB Atlas: 404 IP Address 10.1.100.0/24 not on Atlas whitelist for group 5aba24a197019902d2e2698c.
hey @jagregory thanks a lot for reporting that. I will look into it when I get some free time. If you want to give it a shot and submit a PR happy to review that as well :)
I have multiple IP whitelist resources set up for the same project, but they seem to behave inconsistently.
Behaviour: Initial
terraform apply
succeeds; subsequent apply's seem to get increasingly confused about what the whitelists are. It seems that it wasn't able to correctly link the resources to their representation from Atlas.Terraform apply run 1:
Terraform apply run 2 (no changes to templates):
Terraform apply run 3 (still no changes to templates):