Skip to content

Atlas

Share your idea. In order to help prioritize, please include the following information

  1. A brief description of what you are looking to do
  2. How you think this will help
  3. Why this matters to you

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback

43 results found

  1. The IPs of the newly created cluster should be in the terraform state directly

    We are trying to deploy a cluster in Azure using Terraform and then inspect the newly created cluster to get the hostnames and IP addresses. We need these IP Addresses so we update the Azure Firewall to allow the Azure Key Vault to communicate with the Atlas cluster. We are doing this test to enable encryption at rest with our own keys.

    We believe the IPs should be in the terraform state directly.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  2. Ideally migration of terraform state should be handled or provide a tool for migrating state

    Hello,
    We initially rolled out all our clusters with mongo atlas terraform provider version 0.7.0. Since we hadn't pinned the version, we started seeing warning listed below in the terraform plan.

    Updating as indicated based on the warning means, a deletion and recreation of the private endpoint/link related resources which will lead to downtime as the cluster will be inaccessible while the private endpoint/link is being recreated.

    Ideally migration of terraform state should be handled or provide a tool for migrating state so the resource can be migrated without recreation.

    ============================================

    There are warnings related to your configuration. If no…

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  3. Indicate operation errors already in the plan phase

    This idea originates from my original bug report: https://github.com/mongodb/terraform-provider-mongodbatlas/issues/284

    Changing the name of an existing custom_db_role is currently not possible without ending in an error in the apply step. The plan for a name change currently indicates the replacement due to the name change:

    # module.versioner.mongodbatlas_custom_db_role.this must be replaced
    -/+ resource "mongodbatlas_custom_db_role" "this" {
        ~ id         = "someid" -> (known after apply)
            project_id = "5c860ed2a6f2396cd47f4785"
        ~ role_name  = "old_name" -> "newName" # forces replacement
    

    Applying this results in the following error:

    Error: error deleting custom db role (mongoversioner): DELETE https://cloud.mongodb.com/api/atlas/v1.0/groups/projectid/customDBRoles/roles/old_name: 409 (request "Conflict") Deleting specified custom role would leave the…

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
1 3 Next →
  • Don't see your idea?

Feedback and Knowledge Base