Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes to mongodbatlas_database_user.role.collection_name are ignored #228

Closed
dijitali opened this issue May 18, 2020 · 4 comments
Closed
Labels

Comments

@dijitali
Copy link

dijitali commented May 18, 2020

Setup

I created a database user like this (provider version 0.5.1):

provider "mongodbatlas" {
  version     = "~> 0.5"
  public_key  = var.mongodbatlas_public_key
  private_key = var.mongodbatlas_private_key
}

resource "mongodbatlas_database_user" "my-service" {
  username           = "terraformed-test-user"
  password           = random_password.store-service-password.result
  project_id         = var.project_id
  auth_database_name = "admin"

  roles {
    role_name       = "read"
    database_name   = "trinity"
    collection_name = "stir"

  }

  roles {
    role_name       = "read"
    database_name   = "trinity"
    collection_name = "unpledged"
  }
}

Which created me a user just fine (screenshot from Mongo Atlas portal):
image

> db.getUser("terraformed-test-user")
{
        "_id" : "admin.terraformed-test-user",
        "user" : "terraformed-test-user",
        "db" : "admin",
        "roles" : [
                {
                        "role" : "xgen-readAttrinity.stir",
                        "db" : "admin"
                },
                {
                        "role" : "xgen-readAttrinity.unpledged",
                        "db" : "admin"
                }
        ]
}

The problem

I then removed one of the roles and removed the optional collection_name attribute:

resource "mongodbatlas_database_user" "my-service" {
  username           = "terraformed-test-user"
  password           = random_password.store-service-password.result
  project_id         = var.project_id
  auth_database_name = "admin"

  roles {
    role_name     = "read"
    database_name = "trinity"
  }
}

I see that the second role has been removed correctly, but the change to remove the collection_name from the first role hasn't been detected.

Terraform will perform the following actions:

  # mongodbatlas_database_user.my-service will be updated in-place
  ~ resource "mongodbatlas_database_user" "my-service" {
        auth_database_name = "admin"
        id                 = "cHJvamVjdF9pZA==:NWExNmNmYjIwYmQ2NmIxZGQzMmViYThh-dXNlcm5hbWU=:dGVycmFmb3JtZWQtdGVzdC11c2Vy-YXV0aF9kYXRhYmFzZV9uYW1l:YWRtaW4="
        password           = (sensitive value)
        project_id         = "<REMOVED>"
        username           = "terraformed-test-user"
        x509_type          = "NONE"

        roles {
            collection_name = "stir"
            database_name   = "trinity"
            role_name       = "read"
        }
      - roles {
          - collection_name = "unpledged" -> null
          - database_name   = "trinity" -> null
          - role_name       = "read" -> null
        }
    }

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

And if I check in the DB:
image

> db.getUser("terraformed-test-user")
{
        "_id" : "admin.terraformed-test-user",
        "user" : "terraformed-test-user",
        "db" : "admin",
        "roles" : [
                {
                        "role" : "xgen-readAttrinity.stir",
                        "db" : "admin"
                }
        ]
}
@themantissa
Copy link
Collaborator

@dijitali thank you for the excellent write up. I'll ask our developers to take a look at this potential bug.

@PacoDw
Copy link
Contributor

PacoDw commented May 19, 2020

Hello @dijitali thank you so much for your review, it helped a lot, it already fixed if you want more details or test the fix you can check the pr #231.

Let me know if you have another comment or concern, thanks

@PacoDw PacoDw closed this as completed in baa3ed6 May 27, 2020
@dijitali
Copy link
Author

@PacoDw thanks for the prompt turnaround here!

Unfortunately I'm not in a position to easily test #231 with our pipeline until it's released, do you know when the next provider version is likely to land that'll include this fix?

@themantissa
Copy link
Collaborator

@dijitali we expect to have a release with this coming very soon. If you are okay with waiting for that just keep an eye out for the update here. TY!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants