73 results found

1. If you select "Collections" on a database, and you don't have at least "Project Data Access Read Only" access, you get an unhelpful message

   If you don't have the access righrts to read data, instead of a suitable message, you get "An error occurred while querying your MongoDB deployment.
   Please try again in a few minutes."
   Totally unhelpful, as trying again won't fix your permissions!

   •  

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Data Explorer  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. Add v1.5 API support to Terraform to support asymmetric hardware

   We use a base tier MongoDB cluster (M20) and an analytics tier (M30), where they are of different sizes due to different business requirements.

   Currently this is not supported by Terraform unless tiers use the same hardware (e.g. either both are set to M20 or M30).

   See the error message below.

   Error: error reading MongoDB Cluster (development): GET https://cloud.mongodb.com/api/atlas/v1.0/groups/1234567890/clusters/development: 400 (request "ASYMMETRICHARDWAREINVALID") Asymmetric hardware is not supported by the v1.0 API. Please use the v1.5 API instead. Documentation for the v1.5 API is available at https://docs.atlas.mongodb.com/reference/api/clusters-advanced/.

   Please add v1.5 API support to Terraform to support asymmetric hardware.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   completed  ·  1 comment  ·  Terraform Provider  ·  Delete…  ·  Admin →

3. Allow OpLog Backups in Atlas M0-M5 Shared-Tier clusters running on MongoDB v.5.x

   I have a backup process that is taking hourly dumps of the oplog on my production cluster running MongoDB v.5.0.6.

   It works fine using older versions of mongodump. However, when I update my tools to any version higher than 100.3.1 (100.4.x and above), my oplog backups fail with the following error:

   CMD : 2022-02-16T15:39:03.186-0500  Failed: error creating intents to dump: error counting local.oplog.rs: (Location40602) $collStats is only valid as the first stage in a pipeline.
   

   According to Atlas Support, this issue is limited to M0-M5 clusters and will need to be addressed by the Atlas development team.

   Can I ask that this be looked at so that we can keep up with the latest tool and cluster versions without sacrificing our opLog backup strategy?

   I have a backup process that is taking hourly dumps of the oplog on my production cluster running MongoDB v.5.0.6.

   It works fine using older versions of mongodump. However, when I update my tools to any version higher than 100.3.1 (100.4.x and above), my oplog backups fail with the following error:

   CMD : 2022-02-16T15:39:03.186-0500  Failed: error creating intents to dump: error counting local.oplog.rs: (Location40602) $collStats is only valid as the first stage in a pipeline.
   

   According to Atlas Support, this issue is limited to M0-M5 clusters and will need to be addressed by the Atlas development team.

   Can I ask… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Backup  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

4. Allow to provide names/descriptions for peering connections

   If the user has 3 peering connections in a project, it's error prone terminating one, as you may end the connection with the wrong VPC and cause a disaster. Adding a description field allows to clearly see the purpose of the peering.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

5. Enable and disable balancing on a collection

   Shell commands sh.enableBalancing() and sh.disableBalancing() were not permitted on Atlas hosted MongoDB. Is it possible to grant this permission?
   Currently it failed with error:
   
uncaught exception: Error: command failed: {
"ok" : 0,
"errmsg" : "not authorized on config to execute command { update: \"collections\", ordered: true, writeConcern: { w: \"majority\", wtimeout: 60000.0 }, lsid: { id: UUID(\"ed83ed26-e07b-4f34-a90a-a145bbe58a48\") }, $clusterTime: { clusterTime: Timestamp(1646788928, 17), signature: { hash: BinData(0, 347249E35ED43BDADAE12FB0F794C091CB86206E), keyId: 7052082196881866761 } }, $db: \"config\" }",
"code" : 13,
"codeName" : "Unauthorized",
"operationTime" : Timestamp(1646788928, 18),
"$clusterTime" : {
"clusterTime" : Timestamp(1646788928, 18),
"signature" : {
"hash" : BinData(0,"NHJJ417UO9ra4S+w95TAkcuGIG4="),
"keyId" : NumberLong("7052082196881866761")
}
}
} :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
doassert@src/mongo/shell/assert.js:18:14
_assertCommandWorked@src/mongo/shell/assert.js:710:13
assert.commandWorked@src/mongo/shell/assert.js:811:16
sh.disableBalancing@src/mongo/shell/utils_sh.js:282:12
@(shell):1:1


   Shell commands sh.enableBalancing() and sh.disableBalancing() were not permitted on Atlas hosted MongoDB. Is it possible to grant this permission?
   Currently it failed with error:
   
uncaught exception: Error: command failed: {
"ok" : 0,
"errmsg" : "not authorized on config to execute command { update: \"collections\", ordered: true, writeConcern: { w: \"majority\", wtimeout: 60000.0 }, lsid: { id: UUID(\"ed83ed26-e07b-4f34-a90a-a145bbe58a48\") }, $clusterTime: { clusterTime: Timestamp(1646788928, 17), signature: { hash: BinData(0, 347249E35ED43BDADAE12FB0F794C091CB86206E), keyId: 7052082196881866761 } }, $db: \"config\" }",
"code" : 13,
"codeName" : "Unauthorized",
"operationTime" : Timestamp(1646788928, 18),
"$clusterTime" : {
"clusterTime" : Timestamp(1646788928, 18),
"signature" : {
"hash" : BinData(0,"NHJJ417UO9ra4S+w95TAkcuGIG4="),
"keyId"… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

6. connecting from ubuntu to mongodb atlas is terrible

   kamal@zehan:~/Desktop/mongodb$ mongo "mongodb+srv://cluster0.d9ct7.mongodb.net/myFirstDatabase" --username mongo
   MongoDB shell version v5.0.5
   Enter password:
   connecting to: mongodb://cluster0-shard-00-00.d9ct7.mongodb.net:27017,cluster0-shard-00-02.d9ct7.mongodb.net:27017,cluster0-shard-00-01.d9ct7.mongodb.net:27017/myFirstDatabase?compressors=disabled&gssapiServiceName=mongodb&ssl=true

   *** You have failed to connect to a MongoDB Atlas cluster. Please ensure that your IP allowlist allows connections from your network.
   Error: bad auth : Authentication failed. :
   connect@src/mongo/shell/mongo.js:372:17
   @(connect):2:6
   exception: connect failed
   exiting with code 1

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

7. Metrics charts x-axis showing more than 24 hours of data should be labeled according to the scale

   Metrics charts x-axis showing more than 24 hours of data should be labeled according to the scale

   Currently, when a mouse is not hovering over a Metrics plot, the plot will show particular hours as labels for the x-axis. For example, if an 8 hour range of time is displayed, the time every two hours will be labeled.

   However, if more than 1 day is displayed, the x-axis labels are less useful. The particular time once/day is displayed, but the day is not included. For example, when I display a week of data, 07:00 is highlighted on each particular day, but it is not clear which day that is (unless if I hover over the chart).

   This is even worse if more than 1 week is selected -- in that case, two 07:00 times are displayed, with no indication of the date. It's impossible to gauge when a trend started or changed based on the labels alone.

   It would be better if the date were included or shown instead as the label for plots that show a wider date range.

   Metrics charts x-axis showing more than 24 hours of data should be labeled according to the scale

   Currently, when a mouse is not hovering over a Metrics plot, the plot will show particular hours as labels for the x-axis. For example, if an 8 hour range of time is displayed, the time every two hours will be labeled.

   However, if more than 1 day is displayed, the x-axis labels are less useful. The particular time once/day is displayed, but the day is not included. For example, when I display a week of data, 07:00 is highlighted on each particular day,… more

   •  

   •  

   •  

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Monitoring and Metrics  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

8. Add a datasource for members of an organization

   Problem: The mongodbatlas_teams resource only works with email addresses of user accounts which are existing members of the organization at apply time¹, and Team memberships can't (yet?) be managed via Identity Federation (third-party SAML IdP).

   Solution: If there was a datasource using the "Get All Organization Users" API² to return a list of organization members, that data could be used to filter the usernames input attribute of the mongodbatlas_teams resource to only add valid users.

   Workaround: We're using a Python script as an external datasource to get the data needed to perform said filtering.

   ¹: An error is thrown when trying to add a user who hasn't logged into Atlas or isn't part of the organization: 401 (request "NOT_USER_ADMIN") The currently logged in user does not have the user administrator role for any group, team, or organization containing user.

   ²: https://www.mongodb.com/docs/atlas/reference/api/organization-users-get-all-users/#get-all-organization-users

   Problem: The mongodbatlas_teams resource only works with email addresses of user accounts which are existing members of the organization at apply time¹, and Team memberships can't (yet?) be managed via Identity Federation (third-party SAML IdP).

   Solution: If there was a datasource using the "Get All Organization Users" API² to return a list of organization members, that data could be used to filter the usernames input attribute of the mongodbatlas_teams resource to only add valid users.

   Workaround: We're using a Python script as an external datasource to get the data needed to perform said filtering.

   ¹: An error is thrown when… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Terraform Provider  ·  Delete…  ·  Admin →
   completed  ·  Zuhair responded

   this feature has has been released as part of v1.10.0 release. thank you for the feedback. 

   
   

   for more details see: https://registry.terraform.io/providers/mongodb/mongodbatlas/latest/docs/data-sources/organizations

9. Data migration from Cloud manager to Atlas

   With reference to case https://support.mongodb.com/case/00918578 we experienced situation where the migration was in a stuck state eternally. If the validation checks fail, then it is only fair and logical to fail the migration with a relevant error rather than the status lying about your shard migration is in progress.

   Also, emit status updates on the migration, such as pre-validation checks passed, syncing data, and % complete on data migration or initial sync rather than just a green bar, and whatever else such as if it is building indexes, etc during migration. Basically, make the status as readable and logical as possible, and please introduce a timeout if the data migration isn't going on for real. I understand that you can't timeout since the time on migration can depend on the size of data but try to make the migration intelligent. It is very dumb atm.

   With reference to case https://support.mongodb.com/case/00918578 we experienced situation where the migration was in a stuck state eternally. If the validation checks fail, then it is only fair and logical to fail the migration with a relevant error rather than the status lying about your shard migration is in progress.

   Also, emit status updates on the migration, such as pre-validation checks passed, syncing data, and % complete on data migration or initial sync rather than just a green bar, and whatever else such as if it is building indexes, etc during migration. Basically, make the status as readable and logical as… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

10. Data Usage Reporting & Improved Profiler

    The Current Problem:
    The existing issue stems from MongoDB's inability to provide concrete evidence supporting the data charges for your data usage. This predicament becomes especially troublesome when your system typically operates within a data usage threshold of less than 100GB daily. Suddenly, over a span of 7 days, you are billed for data usage exceeding 1000-2000GB daily, only to subsequently revert to using less than 100GB daily. The absence of substantiated evidence leaves you in a quandary, unsure whether the issue lies with your system or is a reporting error on MongoDB's part. MongoDB Support relies on the slowest queries from the profiler as evidence; however, it's essential to note that these queries have persisted both before and after the anomaly.

    Feature Request:
    The proposed feature request centers on the creation of improved data usage reporting, aiming to address the aforementioned challenges. This feature would empower users to access comprehensive data consumption reports which would provide quantifiable evidence to reconcile data usage discrepancies. Key additions include enhancing the Profiler to provide an option to display all queries, not limited to just the slow queries. Additionally, a report should be introduced, offering precise insights into data usage, broken down by cluster, node, and collections per day. This report should tally the number of queries to each collection, along with the amount of data retrieved by each IP Address and user that queried that collection. These comprehensive reports are pivotal in facilitating a more effective understanding of invoices and Atlas Costs.

    The Current Problem:
    The existing issue stems from MongoDB's inability to provide concrete evidence supporting the data charges for your data usage. This predicament becomes especially troublesome when your system typically operates within a data usage threshold of less than 100GB daily. Suddenly, over a span of 7 days, you are billed for data usage exceeding 1000-2000GB daily, only to subsequently revert to using less than 100GB daily. The absence of substantiated evidence leaves you in a quandary, unsure whether the issue lies with your system or is a reporting error on MongoDB's part. MongoDB Support relies on the slowest… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Billing  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

11. Terraform Downward Autoscaling "Use Smallest possible" placeholder

    When setting "providerautoscalingcomputemininstancesize", is it possible to either;

    • Loosen the validation by ignoring current disk configuration size.
    • Create a placeholder to indicate "Use smallest possible value".

    Atlas appears to support invalid values, provided it was entered when it was valid.

    ---

    I think this will help simplify deployment of "providerautoscalingcomputemininstancesize", we set the ideal value and THE MACHINE will interpret the best match and remove the possibility of a once valid Terraform definition becoming invalid without any updates on the definition. Like the following example,
    1. I define an M30 Cluster with a Disk Size of 64gb and a minimum Cluster size of M10 through Terraform.
    2. The Cluster's Disk Size is scaled to 129gb
    3. Time passes.
    4. I execute/run my previously valid Terraform definition, Terraform returns a validation failure.

    ---

    This matters to us because it would simplify our MongoDB operations. "providerautoscalingcomputemininstancesize" is a parameterized value where, if empty, we use an instance size of M10. Having the deployment fail unexpectedly when updating/creating a cluster can be a frustrating experience (Especially when people do not read error messages).

    When setting "providerautoscalingcomputemininstancesize", is it possible to either;

    • Loosen the validation by ignoring current disk configuration size.
    • Create a placeholder to indicate "Use smallest possible value".

    Atlas appears to support invalid values, provided it was entered when it was valid.

    ---

    I think this will help simplify deployment of "providerautoscalingcomputemininstancesize", we set the ideal value and THE MACHINE will interpret the best match and remove the possibility of a once valid Terraform definition becoming invalid without any updates on the definition. Like the following example,
    1. I define an… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Terraform Provider  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

12. Support safe handling of shared project IP access list entries in Terraform (prevent deletes when the same IP is used by multiple services).

    Description:
    We are facing an issue managing project-level IP access lists in MongoDB Atlas when multiple services/profiles share the same IP address.

    Scenario:

    One Atlas Project.

    Service is deployed with different cluster profiles (e.g., integration, testing).

    Each profile’s Terraform stack provisions:

    An Atlas cluster (mongodbatlasadvancedcluster)

    A backup schedule (mongodbatlascloudbackup_schedule)

    A project IP access list entry (mongodbatlasprojectipaccesslist) using the same IP address.

    Behavior Observed:

    Integration profile deployment:

    Creates cluster, backup, and adds Gateway IP to the project access list. ✅

    Testing profile deployment (same service, different profile):

    Creates a second cluster and backup.

    Attempts to add the same NAT Gateway IP.

    Atlas API accepts it (idempotent) → no duplicate error, but no new entry is created either.

    Terraform state for the testing profile still assumes ownership of that IP entry.

    Delete testing profile:

    Destroys cluster and backup.

    Also deletes the NAT Gateway IP from the Atlas project (because state thinks it owns it).

    ❌ Result: the integration profile’s cluster loses access, since the shared IP entry is gone.

    Problem:

    mongodbatlasprojectipaccesslist does not support safe handling of shared IPs across multiple Terraform states.

    Unlike AWS Security Group rules (which have unique IDs per rule, making deletes safe), Atlas identifies IPs only by the IP address string.

    This creates a state ownership conflict: one stack can remove IPs required by another.

    Description:
    We are facing an issue managing project-level IP access lists in MongoDB Atlas when multiple services/profiles share the same IP address.

    Scenario:

    One Atlas Project.

    Service is deployed with different cluster profiles (e.g., integration, testing).

    Each profile’s Terraform stack provisions:

    An Atlas cluster (mongodbatlasadvancedcluster)

    A backup schedule (mongodbatlascloudbackup_schedule)

    A project IP access list entry (mongodbatlasprojectipaccesslist) using the same IP address.

    Behavior Observed:

    Integration profile deployment:

    Creates cluster, backup, and adds Gateway IP to the project access list. ✅

    Testing profile deployment (same service, different profile):

    Creates a second cluster and backup.

    … more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Terraform Provider  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

13. Support safe handling of shared project IP access list entries in Terraform (prevent deletes when the same IP is used by multiple services).

    Description:
    We are facing an issue managing project-level IP access lists in MongoDB Atlas when multiple services/profiles share the same IP address.

    Scenario:

    One Atlas Project.

    Service is deployed with different cluster profiles (e.g., integration, testing).

    Each profile’s Terraform stack provisions:

    An Atlas cluster (mongodbatlasadvancedcluster)

    A backup schedule (mongodbatlascloudbackup_schedule)

    A project IP access list entry (mongodbatlasprojectipaccesslist) using the same IP address.

    Behavior Observed:

    Integration profile deployment:

    Creates cluster, backup, and adds Gateway IP to the project access list.

    Testing profile deployment (same service, different profile):

    Creates a second cluster and backup.

    Attempts to add the same Gateway IP.

    Atlas API accepts it (idempotent) → no duplicate error, but no new entry is created either.

    Terraform state for the testing profile still assumes ownership of that IP entry.

    Delete testing profile:

    Destroys cluster and backup.

    Also deletes the Gateway IP from the Atlas project (because state thinks it owns it).

    Result: the integration profile’s cluster loses access, since the shared IP entry is gone.

    Problem:

    mongodbatlasprojectipaccesslist does not support safe handling of shared IPs across multiple Terraform states.

    Unlike AWS Security Group rules (which have unique IDs per rule, making deletes safe), Atlas identifies IPs only by the IP address string.

    This creates a state ownership conflict: one stack can remove IPs required by another.

    Description:
    We are facing an issue managing project-level IP access lists in MongoDB Atlas when multiple services/profiles share the same IP address.

    Scenario:

    One Atlas Project.

    Service is deployed with different cluster profiles (e.g., integration, testing).

    Each profile’s Terraform stack provisions:

    An Atlas cluster (mongodbatlasadvancedcluster)

    A backup schedule (mongodbatlascloudbackup_schedule)

    A project IP access list entry (mongodbatlasprojectipaccesslist) using the same IP address.

    Behavior Observed:

    Integration profile deployment:

    Creates cluster, backup, and adds Gateway IP to the project access list.

    Testing profile deployment (same service, different profile):

    Creates a second cluster and backup.

    Attempts… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Terraform Provider  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating