500 response on /groups/GROUP-ID/peers

[igaskin]

Error: error creating MongoDB Network Peering Connection: POST https://cloud.mongodb.com/api/atlas/v1.0/groups/GROUP-ID/peers: 500 (request "Internal Server Error") Unexpected error.

  on atlas.tf line 111, in resource "mongodbatlas_network_peering" "eu_west_1":
 111: resource "mongodbatlas_network_peering" "eu_west_1" {

Terraform CLI and Terraform MongoDB Atlas Provider Version

terraform version
Terraform v0.13.3
+ provider registry.terraform.io/-/aws v3.8.0
+ provider registry.terraform.io/-/mongodbatlas v0.6.5
+ provider registry.terraform.io/-/random v2.3.0
+ provider registry.terraform.io/hashicorp/aws v3.8.0
+ provider registry.terraform.io/hashicorp/random v2.3.0
+ provider registry.terraform.io/mongodb/mongodbatlas v0.6.5```

### Terraform Configuration File 

```hcl
resource "mongodbatlas_network_peering" "eu_west_1" {
  accepter_region_name   = "eu-west-1"
  project_id             = var.project_id
  provider_name          = var.provider_name
  aws_account_id         = data.aws_caller_identity.default.account_id
  vpc_id                 = var.vpc_ids["eu_west_1"]
  route_table_cidr_block = var.vpc_cidrs["eu_west_1"]
  container_id           = mongodbatlas_network_container.eu_west_1.id
}```

### Steps to Reproduce
1. `terraform init`
2. `terraform apply`

### Expected Behavior
Succeed with 200

### Actual Behavior
Fails with 500

[nikhil-mongo]

@igaskin Please refer to the linked repo for setting up the VPC Peering from Atlas to AWS.
You may need to change some attributes' values. Let us know if this helps you.
Thanks

[igaskin]

@nikhil-mongo thanks for sharing the sample repo. The code in the repo matches the attributes that I've set on my end as well. If you are unable to reproduce the issue, then feel free to close this issue. I was never actually able to successfully run this end-to-end. I had to manually create resources and import them into my terraform state

[nikhil-mongo]

@igaskin When I compared your shared code with the sample-repo, I found the below difference. And, I was able to repro the error you mentioned which I why I shared the sample repo.

Your code:

container_id           = mongodbatlas_network_container.eu_west_1.id

Sample Repo:

  container_id           = mongodbatlas_network_container.atlas_container.container_id

This causes the 500 error. Please fix this and you should be able to do it via terraform.

[igaskin]

Ah, thanks for pointing that out! Is there value of exposing id as a resource attribute for mongodbatlas_network_container? The docs read:

id - Terraform's unique identifier used internally for state management.

This makes me believe that the .id attribute is only used internally by terraform, and would/should not be exposed as an input/output attribute that users interact with. Typically the .id attribute is directly related to the resource and not the state, ex: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/vpc_peering_connection#attributes-reference

Any thoughts on using the .id as an alias for container_id?

[nikhil-mongo]

@igaskin Yes, you are right.

The .id attribute is Terraform's unique identifier used internally for state management.

And I could see that both these values .id and container.id are same in the tfstate file.

@themantissa Is there any possibility of doing this or any implications if we do this?

[themantissa]

The are two different values - the id will return the actual Terraform id from state, which can be useful when situations arise where you need to interact with state: https://www.terraform.io/docs/commands/state/index.html for example list takes the state id.

The container id returns the value Atlas gives the container - https://docs.atlas.mongodb.com/reference/api/vpc-get-containers-list/ (it may look the same in the state file but when returned it's the actual Atlas container id).

[igaskin]

Understood. This is the first example I've seen of a provider exposing the state id directly in a resource's attributes, which is what caused my confusion. Arguably a more idiomatic way of interacting with the state in HCL is via the terraform_remote_state data object.

data "terraform_remote_state" "vpc" {
  backend = "remote"
 ...
}

Given that this is an intentional design choice of the mongodbatlas provider, we should close this issue.

[themantissa]

@coderGo93 and @leofigy I'll lean on you both to provide context around why we exposed this directly.

After giving our development team time to respond I'll close this issue, thank you @igaskin

[leofigy]

Hi @igaskin

You're right is a design decision, there is a composed id per resource that is used to get an easy path for import terraform resources. Now for this use case, I agree it's a bit confusing to have two ids attributes, one as the mongodbatlas id that you need to reference as an attribute in another resource and the internal one. It would be handy to have a unique that works in the attributes reference. Thanks for pointing this out.

[themantissa]

Thank you @leofigy ! @igaskin hope that helps and we plan to improve this in the future. I'll close this for now. Thanks again!