IP allowlist range force replacement on 1.12.0

[wyardley]

Terraform CLI and Terraform MongoDB Atlas Provider Version

Terraform v1.5.7
on darwin_arm64
+ provider registry.terraform.io/hashicorp/random v3.5.1
+ provider registry.terraform.io/mongodb/mongodbatlas v1.12.0

Terraform Configuration File

resource "mongodbatlas_project_ip_access_list" "allowed_ip_cidr_range" {
  for_each = merge(
    data.terraform_remote_state.xyz.outputs.vpc_xx_ip_secondary_ranges,
    data.terraform_remote_state.xyz.outputs.vpc_subnet_and_connector_ranges,
    data.terraform_remote_state.nnn.outputs.vpc_yy_ip_secondary_ranges,
    data.terraform_remote_state.nnn.outputs.vpc_subnet_ranges,
  )
  project_id = mongodbatlas_project.xxx.id
  cidr_block = each.value["ip_cidr_range"]
  comment    = "VPC: ${element(split("/", each.value["network"]), length(split("/", each.value["network"])) - 1)}; Subnet: ${each.value["name"]}"
}

Steps to Reproduce

Expected Behavior

No change / drift

Actual Behavior

  # mongodbatlas_project_ip_access_list.allowed_ip_cidr_range["xxx"] must be replaced
-/+ resource "mongodbatlas_project_ip_access_list" "allowed_ip_cidr_range" {
      + aws_security_group = (known after apply) # forces replacement
      ~ id                 = "ZW50cnk=:MTAwLjEyNy4xOTIuODAvMjg=-cHJvamVjdF9pZA==:NjExY2IyNTk2MDZiNjQ3ZmY0NWRmNzIx" -> (known after apply)
      + ip_address         = (known after apply) # forces replacement
        # (3 unchanged attributes hidden)

      - timeouts {}
    }

  # mongodbatlas_project_ip_access_list.allowed_ip_cidr_range["yyy"] must be replaced
-/+ resource "mongodbatlas_project_ip_access_list" "allowed_ip_cidr_range" {
      + aws_security_group = (known after apply) # forces replacement
      ~ id                 = "ZW50cnk=:MTAuMi4wLjAvMjA=-cHJvamVjdF9pZA==:NjExY2IyNTk2MDZiNjQ3ZmY0NWRmNzIx" -> (known after apply)
      + ip_address         = (known after apply) # forces replacement
        # (3 unchanged attributes hidden)

      - timeouts {}
    }

  # mongodbatlas_project_ip_access_list.allowed_ip_cidr_range["zzz"] must be replaced
-/+ resource "mongodbatlas_project_ip_access_list" "allowed_ip_cidr_range" {
      + aws_security_group = (known after apply) # forces replacement
      ~ id                 = "ZW50cnk=:MTAuMi4xNi4wLzIw-cHJvamVjdF9pZA==:NjExY2IyNTk2MDZiNjQ3ZmY0NWRmNzIx" -> (known after apply)
      + ip_address         = (known after apply) # forces replacement
        # (3 unchanged attributes hidden)

      - timeouts {}
    }

Debug Output

Crash Output

Additional Context

• Note: there is no AWS involved - all of these are GCP VPCs. so not sure about the aws_security_group bit, whether that's a red herring or relevant.
• I can't easily provide the full debug output, but if there's something you want me to look at and send sanitized or outside of GitHub, let me know
• I have a similar setup in another 2 mongo projects without similar behavior.

References

Not sure if this could be related to #1493 somehow

[github-actions]

Thanks for opening this issue. The ticket INTMDB-1138 was created for internal tracking.

[wyardley]

ps - I was able to get it to plan cleanly with both old and new provider by doing a tf state rm [affected resource] for the 3 that were planning weird, and then importing the resource.

That seems to work, though if I plan the state that was applied w/ 1.12.0, I now get an error if I apply with the previous version again:

│ Error: error getting database user information: groupID is invalid because must be set
│ 
│   with module.mongodb_users.mongodbatlas_database_user.user["xyz"],

[maastha]

Hi @wyardley Is it possible to share the original state of one of these affected resources from the statefile so we could try to compare for ourselves?
This resource was recently refactored to use Terraform plugin Framework and this could help us quickly reproduce the issue

[wyardley]

Hi - thanks. I don't believe I have that version of the state accessible easily -- sorry.

[maastha]

No worries, we will try to reproduce this on our end.

[cah6]

Hey there,

I'm running into this as well. If it helps in your repro, my current state (some values ...'d):

$ tf state show 'module.ip_access_list.mongodbatlas_project_ip_access_list.main["1.2.3.4/20"]'
resource "mongodbatlas_project_ip_access_list" "main" {
    cidr_block = "1.2.3.4/20"
    comment    = "..."
    id         = "ZW50cnk=:MTAuOC4xNi4wLzIw-cHJvamVjdF9pZA==:NWQ1NjFjOGVjZjA5YTI3OGQyY2Y0YjM2"
    project_id = "..."

    timeouts {}
}

here's my module definition:

resource "mongodbatlas_project_ip_access_list" "main" {
  for_each = var.ip_access_data

  project_id = var.project_id
  cidr_block = each.key
  comment    = each.value
}

and here's what the plan gives:

  # module.ip_access_list.mongodbatlas_project_ip_access_list.main["1.2.3.4/20"] must be replaced
-/+ resource "mongodbatlas_project_ip_access_list" "main" {
      + aws_security_group = (known after apply) # forces replacement
      ~ id                 = "ZW50cnk=:MTAuOC4xNi4wLzIw-cHJvamVjdF9pZA==:NWQ1NjFjOGVjZjA5YTI3OGQyY2Y0YjM2" -> (known after apply)
      + ip_address         = (known after apply) # forces replacement
        # (3 unchanged attributes hidden)

      - timeouts {}
    }

FWIW I figured it wouldn't matter but I also tried explicitly setting aws_security_group and ip_address to null in my definition, but that didn't change anything.

Just wanted to drop this here if it helps, I'll probably also be doing a tf state rm ... and re-import today to get around this.

[maastha]

Hi @cah6 could you please share the previous version of the provider you used to create these resources before upgrading to 1.12.0?

I have tried reproducing this but unsuccessful so far. Here are the steps I tried:

1. Create mongodbatlas_project_ip_access_list resource with v1.11.1 with below config:

resource "mongodbatlas_project_ip_access_list" "allowed_ip_cidr_range" {
  for_each = {
    for index, cidr in local.cidr_block_list :
    cidr.comment => cidr
  }
  project_id = mongodbatlas_project.main.id
  cidr_block = each.value.cidr_block
  comment    = each.value.comment
}

2. terraform state:

terraform state show 'mongodbatlas_project_ip_access_list.allowed_ip_cidr_range["CIDR Block 1"]'

# mongodbatlas_project_ip_access_list.allowed_ip_cidr_range["CIDR Block 1"]:
resource "mongodbatlas_project_ip_access_list" "allowed_ip_cidr_range" {
    cidr_block = "...."
    comment    = "CIDR Block 1"
    id         = "ZW50cnk=:MTAuMS4wLjAvMTY=-cHJvamVjdF9pZA==:NjRkYjVkNTAzYjk2MTI0YjBlODI4MmRj"
    project_id = "64db5d503b96124b0e8282dc"

3. upgrade to 1.12.0 and run terraform plan:

No changes. Your infrastructure matches the configuration.

Could you please help identifying what might be missing here?

[cah6]

@maastha these resources were originally created with version 1.8.0, although I believe that when we upgraded to 1.11.1, it successfully planned without needing replacements.

[wyardley]

FWIW, we've been using the provider since 1.3.1 or before; we pin it, and typically update one version at a time when prompted by Renovate.

[maastha]

Hi @cah6 @wyardley
I tried creating the resources with 1.8.0 and upgrade too 1.11.1 and then 1.12.0, my plan is empty in both cases, hence still no luck reproducing this.

Would request you to please share the following:

1. tfstate file for the resource
2. Any relevant logs
3. Steps to reproduce the issue

[wyardley]

I’ve already done the workaround above, so don’t have any of that accessible to me.

the step was just to plan or apply, though.

[cah6]

Yeah, sorry I also already fixed to get past this locally, so can't give the broken tfstate file. I don't think there were any other logs or steps other than planning/applying.

[wyardley]

I ran with TF_log=debug which I assume is what they want, but I didn’t save the output.

[maastha]

@cah6 are you able to share what you had to do to fix this locally?

[github-actions]

This issue has gone 7 days without any activity and meets the project’s definition of "stale". This will be auto-closed if there is no new activity over the next 7 days. If the issue is still relevant and active, you can simply comment with a "bump" to keep it open, or add the label "not_stale". Thanks for keeping our repository healthy!

[wyardley]

@cah6 are you able to share what you had to do to fix this locally?

I'm assuming they did the same thing I did - remove the resource, and re-import it.

[maastha]

Hi
As mentioned, we have not been able to reproduce this issue on our end, closing this for now, please feel free to re-open if required, with more details. Please refer our Github issue guidelines here when re-opening.
Thank you!